On Fri, May 09, 2025 at 04:53:54PM -0700, Elijah Newren wrote: > 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. The only part that I would count into the category is parts of commit 11, and I'd be okay with dropping it for now. > 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). Yeah, I wouldn't categorize patch 4 into the "not updated" category. It's the ecosystem it depends on that hasn't been updated, which isn't quite the same. > 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. Okay, I'll try to rephrase both the cover letter and the indvidual commit messages to make sufficiently clear that this is only used as supporting evidence that something can be removed. Patrick
