Re: [PATCH v1 00/25] contrib: cleanup

From: Felipe Contreras <felipe.contreras@gmail.com>
Date: May 9, 2014, 02:01 UTC
Message-ID: <536c36fc8e04c_741a161d31095@nysa.notmuch>
In-Reply-To: <CACPiFCJnsu3qw59oK94sP1u0+KBDvne0ZpKS0LMGc_9ge+rJjA@mail.gmail.com>

Martin Langhoff wrote:

Show 10 quoted lines

> On Thu, May 8, 2014 at 8:58 PM, Felipe Contreras <felipe.contreras@gmail.com
> > wrote:
> 
> > Let us be honest, the vast majority of tools in 'contrib/' have no chance
> > of
> > ever graduating, so let's remove them.
> >
> 
> I am curious -- have you checked what parts of contrib downstreams
> package&ship?

I have checked a few, not throughly. From what I can see most of them just copy everything to /usr/share/git without much consideration to what is actually there.

The only exception is the shell completions.

> Are you planning on CC'ing the (inactive) authors/maintainers
> so they know that if they care they should host those elsewhere?

They are already Cc'ed.

Show 5 quoted lines

> My candid opinion is that you're trying to force a group of people to
> undertake a pointless exercise. Contrib in many/most projects is uneven,
> and folks know that. But it gives upstream a chance to push for some
> minimal quality, and in turn it gives visibility to a bunch of sometimes
> useful tools.

Yes, but that's not what our contrib/ is supposed to be. Read conrib/README.

Show 6 quoted lines

> If my code was going to get the axe, I'd be rather pissed off. If Junio is
> in agreement that code quality is bad, or tools should have unit tests,
> then the push could be to address the problem or face removal. For example:
> contrib maintainer, show you're responsive to bug reports on the list, or
> face removal; add unit tests (or explain why they aren't needed) or face
> removal.

That's right, and they are Cc'ed so they can respond. Some tools have only one commit or two, and in those I didn't even bother Cc'ing anyone.

Moreover, it's not enough that they are actively maintained. Accoding to Junio they need to show that they can't work properly out-of-tree, and thus there's a need for them to be in contrib/. Or they are temporarily in contrib/ so they can become part of the core. That doesn't apply to the tools I proposed to remove here.

-- 
Felipe Contreras