Re: [PATCH 1/9] remote-bzr: trivial cleanups

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

 



On Thu, Apr 25, 2013 at 3:30 PM, Thomas Rast <trast@xxxxxxxxxxx> wrote:
> Felipe Contreras <felipe.contreras@xxxxxxxxx> writes:
>
>> But I do not care that much really. The patch is good either way, if
>> you don't like it, you go ahead and fix it, because I won't. I have
>> 174 remote-helper related patches in my queue, and nobody benefits
>> from rambling about a one liner that is obviously correct, not you,
>> not me, not the users, not the developers.
>
> You don't stick to the rules of this project, which have been pointed
> out already:

The rules of the contrib area are different from the ones of the rest
of the project.

> Your project is moving too fast to put up with the established
> procedures in this community.

That's one of the reasons it's in the contrib area.

> In fact you are pretty much holding us hostage with a "take it or keep
> it broken while causing more work" attitude:

I'm the maintainer of this code, so it's my call. If Junio has a
problem with that, I would gladly take my code somewhere else. I doubt
that's in the best interest of anyone.

But if the problem is this particular patch (reaally?), Junio could
just drop this particular patch. Are you seriously suggesting that the
whole contrib/remote-helpers should be dropped because this patch
introduces a one-liner fix without mentioning it in the commit
message? Really? I haven't seen anybody complain about *any* of the
other patches where I "held the project hostage" and refused to fix
the commit message or change the patch.

Other than this instance, show me where exactly did I do that.

>> Junio of course might disagree and drop this patch, but then he would
>> need to deal with the fallout of possible conflicts.
>
> You did not respond well to reviews and criticism.  Even the
> constructive fine-let's-do-the-work-for-him kind that Peff offered.

Define "respond well". If your idea to "respond well" is to say "Yes
sir!" to every criticism, then no, I didn't. OTOH, if it's to reply
and address the issues with objective reasoning and an open mind, I
did.

I don't understand this notion that every review criticism is valid
and correct. They are not, and it's OK to point that out.. really. If
they turn to be valid and correct, the reviewer can surely
counter-argue and substantiate his/her claims.

And I don't recall Peff ever doing this "constructive
fine-let's-do-the-work-for-him" on any contrib/remote-helpers stuff.

> So why is this in git.git?
>
> Why should we take any more contrib additions from you?

Because it's good for the users.

If you are seriously suggesting to drop contrib/remote-helpers, I
suggest that 1) don't do it in the review thread of a trivial patch 2)
start a new thread where you point multiple instances where the
maintainer of the code (me) failed to respond correctly to criticism
(of remote-helpers's code), 3) show how this affects negatively the
project, and 4) ask for new maintainers if the job of the current one
is not deemed up-to-par, and only if no maintainer steps up, drop the
code.

Cheers.

-- 
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




[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]