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

[Junio C Hamano <gitster@pobox.com>]

Patrick Steinhardt <ps@pks.im> 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.