Re: [PATCH v1 04/25] contrib: remove 'buildsystems'

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

 



On Fri, May 9, 2014 at 11:32 AM, Felipe Contreras
<felipe.contreras@xxxxxxxxx> wrote:
> Erik Faye-Lund wrote:
>> On Fri, May 9, 2014 at 10:48 AM, Felipe Contreras
>> <felipe.contreras@xxxxxxxxx> wrote:
>> > Erik Faye-Lund wrote:
>> >> On Fri, May 9, 2014 at 10:14 AM, Felipe Contreras
>> >> <felipe.contreras@xxxxxxxxx> wrote:
>> >> > If you want this script to remain in contrib, please:
>> >> >
>> >> >  a) Write at least a few tests
>> >> >  b) Write some documentation
>> >> >  c) Explain why it cannot live outside the git.git repository like other
>> >> >     tools. [1][2][3]
>> >>
>> >> (Adding Marius, the original author to the CC-list)
>> >>
>> >> Uh, why is such a burden required all of a sudden? contrib/README
>> >> mentions no such requirements, and the scripts have been accepted (and
>> >> maintained) since.
>> >
>> > contrib/README mentions clearly the expectation that these scripts
>> > eventually move to the core once they mature. This is never going to
>> > happen for these.
>>
>> Yes, *expectation*. Not requirement.
>
> That's right, but these tools fail all expectations.
>
>> > It also mentions that inactive ones would be proposed for removal, and
>> > this one is clearly inactive. It has 9 commits (if you count the one
>> > that changes the execution bit).
>>
>> It mentions that Junio *might* suggest things to be removed, not that
>> things *should* be removed if left unmaintained.
>
> That's right.
>
>> And this script is not unmaintained, it's simply just still working.
>
> Prove it.
>
> Either way, if there was people actively caring about these scripts,
> there should be cleanups, tests, documentation. But there's nothing.
>
>> >> Besides, you say "No activity since 2010" - this is not the case,
>> >> bc380fc is from November 2013.
>> >
>> > You think changing the execution bit of a file is considered "activity"?
>>
>> Well, now we're getting into semantics, which I don't care so much
>> about.
>
> Convenient.
>

Yeah, the part above here goes in my "don't argue with idiots, they'll
drag you down to their level and beat you with experience"-filter.
Good luck trying to convince *anyone* with this line of argumentation.

>> It shows some sort of interest in the scripts, at least.
>
> Not it doesn't. Jonathan Nieder updated the execution bit on a bunch of
> scripts in contrib, these being just in the way. It doesn't show
> interest at all.
>

All of those changes relate to the MSVC-build. So it's not "just some
batch-fixup" as you're trying to suggest.

>> >> And there's already *some* documentation in the scripts themselves.
>> >
>> > That's nice. So you can just copy that into a README.
>>
>> Feel free to scratch that itch yourself, you're the one inventing new
>> requirements here.
>
> If you care about these scripts, you have an interesting way of showing
> it.
>
>> >> Please stop your pointless crusade that'll only break other people's work-flows.
>> >
>> > If you care about these scripts, it should be trivial for you to add at
>> > least a few tests, souldn't it?
>>
>> Again, testing this is not my itch. Feel free to scratch that one
>> yourself, but please don't remove the script.
>
> If you don't care that these scripts keep working properly, I don't see
> why anybody else would.
>

You're the one making up requirements for tests here, so this is your
itch. This script gets fixed by it's stake-holders when it breaks, and
that has worked out fine so far.

>> > Please tell me how exactly will your work-flow be broken. More
>> > specifically, tell me why your scripts cannot be moved outside of git,
>> > like git-extras[1], git-deploy[2], git-ftp[3], and countless other
>> > tools.
>>
>> Moving the script out of the repo makes it less convenient to bisect
>> issues with MSVC, as it depends heavily on the top-level Makefile.
>> Moving it out would require figuring out what version of the script
>> matches a given git revision, which is a hassle.
>
> The script doesn't depend on the version of the Makefile, and proof of
> that is that is has *never* been changed even though the Makefile has.

Except it has, in 74cf9bd.
--
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]