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