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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



For discussing these larger changes in the first version you may want to use
the -D option of git format-patch?

2014-05-09 4:01 GMT+02:00 Felipe Contreras <felipe.contreras@xxxxxxxxx>:
> Martin Langhoff wrote:
>> On Thu, May 8, 2014 at 8:58 PM, Felipe Contreras <felipe.contreras@xxxxxxxxx
>> > 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.
>
>> 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.
>
>> 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
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]