Patrick Steinhardt <ps@xxxxxx> writes: > I have used the following reasons for removal: > > - The tool is clearly broken, e.g. it doesn't even compile. > > - The tool hasn't received any updates for at least the last 5 years. > > - The tool has a clear alternative or just isn't useful anymore. I've expressed my opinions on many of the individual patches, but not all of them. For some, it may be better done at 3.0 boundary with the BreakingChanges transition like everybody else, and some others with clear "new home", we can remove them much earlier and independent from 3.0 plan. Some others with no "new home" may be in the gray area, but my gut feeling is that many of them do not need a careful BreakingChanges transition as some others do. > With this model, "contrib/" would be closer to Linux' staging drivers > with the expectation that a tool should eventually be part of proper Git > in case it proves to be useful, or booted out when it doesn't seem to be > getting there. OK. > Another subsequent step would be to split out some parts of "contrib/" > to be hosted in their own hierarchy. CMake, Coccinelle, Unicode updates, > VScode and the like are all tools that are used during development, so > they should probably not be part of "contrib/" but rather of a new > "tools/" hierarchy (we can bikeshed the name at a later point, I'm not > yet doing that in this series). Yeah, I think we had a discussion like this, and I do not remember the new names proposed for things that are out of core but still part of our tree, but "tools" sounds like a good place. > There's also other bits and pieces that serve as examples. I think we > should move these into our documentation instead of having those in > "contrib/". Sounds sensible. Thanks for getting the ball rolling.
