On Sat, Dec 15, 2012 at 1:09 AM, Michael Haggerty <mhag...@alum.mit.edu> wrote:
> 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:

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.


Felipe Contreras
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to