Felipe Contreras [off-list ref] 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 body should provide a meaningful commit message, which:
. explains the problem the change tries to solve, iow, what is wrong
with the current code without the change.
. justifies the way the change solves the problem, iow, why the
result with the change is better.
. alternate solutions considered but discarded, if any.
Your project is moving too fast to put up with the established
procedures in this community.
In fact you are pretty much holding us hostage with a "take it or keep
it broken while causing more work" attitude:
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.
And on top of that, remote helpers are written against an interface that
was designed to allow working with external programs.
So why is this in git.git?
Why should we take any more contrib additions from you?
--
Thomas Rast
trast@{inf,student}.ethz.ch
On Thu, Apr 25, 2013 at 3:30 PM, Thomas Rast [off-list ref] wrote:
Felipe Contreras [off-list ref] writes:
quoted
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.
quoted
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