Re: [PATCH v2 00/11] Spring cleanup of "contrib/"

> On Fri, May 9, 2025 at 2:20 AM Patrick Steinhardt <ps@pks.im> 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.