On Fri, May 9, 2025 at 2:20 AM Patrick Steinhardt <ps@xxxxxx> wrote: > > Hi, > > as I have lamented multiple times multiple times already (e.g. [1]), the > "contrib/" directory is a bit of a mess containing many bits and pieces > that just sit there gathering dust, without getting any maintenance and > sometimes even in a clearly-broken state. So I decided to finally bite > the bullet and do a spring cleanup of "contrib/", which resulted in this > patch series here. > > 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. Do we still want to use your second reason listed as a reason to remove? Junio brought that up on v1, and it bothers me a bit too. Now, if you couple that with "contrib is meant as staging and projects should graduate or be removed", then I'd be fine with it, but you said later in this cover letter that you were going to post that information in a follow-up series. That makes me wonder whether the removal of tools for this reason should be deferred to that later series where that new direction is recorded. That all said, I tried to do a count of which patches used which rationale (though I split out a fourth because it makes more sense to me that way). I see: - broken tool: patches 1, 7 - not updated: patches 4, part of 11 - better alternative: patches 1, 3, 5, 6, 8, 9, 10, part of 11 - already removed with just a stub left behind: patches 2, 3 (Here I excluded patches from the "not updated" category if there was also an additional rationale given in the commit message. For other rationales, I put the patch under each category that was brought up as a reason for retirement.) So this series doesn't rely solely on the "not updated" rationale very much. Even in patch 4 you allude to the fact that you _suspect_ that tool also falls under the "broken tool" category, and in patch 11, you also argue that it should be handled differently if it's useful (which rhymes with saying that a better alternative exists, but isn't the same since one doesn't necessarily exist yet). Anyway, I like the series, I'm just a little uncomfortable with this part of the cover letter and the wording of some of the commit messages. "not updated in 5 years" is good supplemental information, but I think other git contributors reading those commit messages might get the wrong idea and apply it elsewhere.
