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

[Elijah Newren <newren@gmail.com>]

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.