Re: What's cooking in git.git (Dec 2012, #03; Wed, 12)

From: Felipe Contreras <felipe.contreras@gmail.com>
Date: Dec 15, 2012, 07:45 UTC
Message-ID: <CAMP44s0=R3rdnD-Zpzz_7wY6HKKsAL1sPVYh4pc3z1CBbX2ODg@mail.gmail.com>
In-Reply-To: <50CC2244.4040103@alum.mit.edu>

On Sat, Dec 15, 2012 at 1:09 AM, Michael Haggerty <mhagger@alum.mit.edu> wrote:

Show 14 quoted lines

> On 12/15/2012 04:14 AM, Felipe Contreras wrote:
>> I'm going to say it one last time; merging this patch series either
>> creates issues for the users, or not. There is a reality out there,
>> independent of what you, Junio, or me think or say. And the fact is,
>> that if this patch series is going to create issues for the users,
>> *nobody* has pointed out why, so, since there's no evidence for it,
>> the only rational thing to do is believe that there will be no issues
>> for the users.
>>
>> There is no known issue with the code, that is a fact. This code could
>> be easily merged today, and in fact, it was merged by Junio already
>> (but then reverted). There are no positive outcomes from the delay,
>> only negative ones. I will address the minute issue about the extra
>> cruft, eventually.

Couple of facts first: a) This code was already merged b) This code is for a test c) I'm the only developer so far

> Cruft in the codebase is a problem for git *developers* because it makes
> the code harder to maintain and extend.

A problem big enough to warrant the rejection of the patch series? No.

> And therefore cruft is a problem for git *users* because it slows down
> future development (in whatever small amount).

Don't confuse potential issues with real ones. It *might* slow down future development, but will it do it with absolute certainty and beyond any reasonable doubt? No, it might not slow anything at all.

And even if it does, by how much? 50%? 10%? 1%? Chances are it would be barely noticeable to the users.

And even if it was substantial, this is on *test* code. Most users survive just fine with most of the contrib code not having tests at all, they can probably survive with the development of the test code for remote-bzr being a tad slower.

But who are these developers that would be slowed down? So far I'm the only contributor, and I'm not going to be slowed. If and when somebody else contributes, and find his or her development is slowed down by this, he or her would probably start by removing that code his or herself, and submit the appropriate patch.

> Moreover, it is dangerous for a project to accept crufty code based on a
> contributor's promise to clean up the code later:

But it was already accepted: http://git.kernel.org/?p=git/git.git;a=commitdiff;h=ad38af72b334150e6cf1978721c37077ae3c6d7f

The world didn't end the first time, presumably, if this code is accepted again, the world will not end either.

> * The developer might not get around to it, or might take longer than
> expected.

Somebody else could do it. This is collaborative development after all, is it not?

I don't see people halting because something is somebody else's code.

> * Until it is cleaned up, the cruft hinders other potential developers
> to that code.

How many *potential* developers are we talking about? By how much?

> * The presence of cruft lowers the expectation of quality for the whole
> project; cruft breeds more cruft.

Please. This is in test code for the contrib area, most code in that area doesn't even have tests.

> It is simpler and fairer to have a policy "no crufty code" than to try
> to evaluate each instance on a case-by-case basis.

Even then, the problem can be easily solved by simply removing the whole file (contrib/remote-helpers/test-bzr.sh), I say that has more potential to hurt users and developers, but hey, "no crufty code". Since most code in the contrib area doesn't have tests, we would still be following the "policy".

None of this benefits the *real* users one iota.

Anyway, these theoretical minute problems aren't worth worrying about, nor discussing. If you want to damage real users, go ahead.

Cheers.

-- 
Felipe Contreras