From: Junio C Hamano <hidden> Date: 2016-06-15 22:50:59
Ramkumar Ramachandra [off-list ref] writes:
I'm very sorry to have caused so much pain. Yes, I can imagine how
terrible it must be to review several iterations of a simple
documentation patch. Thank you for being so patient with me so far- I
understand if you don't want to do this anymore.
I do spend time proofreading patches before sending them out, but I'm
clearly not very good at it. In future, I'll either try rewriting
entire paragraphs or simply refrain from writing documentation patches.
I do not think that is the lesson you should learn from this exchange. A
major part of Michael's complaint (which I think was justified) was that
he even made a suggestion that is ready to be cut-and-pasted, but your
reroll does not use the suggested phrasing _without_ explaining why it
doesn't.
It is not limited to "documentation patches". If you get a "how about
doing it this way---isn't it cleaner?" suggestion to your code patch, you
at least owe either "yeah, that looks better---thanks, I've used it in
this reroll" or "no, because...; I've used the original" to the person who
tried to help you, no?
I'm very sorry to have caused so much pain. Yes, I can imagine how
terrible it must be to review several iterations of a simple
documentation patch. Thank you for being so patient with me so far- I
understand if you don't want to do this anymore.
I do spend time proofreading patches before sending them out, but I'm
clearly not very good at it. In future, I'll either try rewriting
entire paragraphs or simply refrain from writing documentation patches.
I do not think that is the lesson you should learn from this exchange. A
major part of Michael's complaint (which I think was justified) was that
he even made a suggestion that is ready to be cut-and-pasted, but your
reroll does not use the suggested phrasing _without_ explaining why it
doesn't.
It is not limited to "documentation patches". If you get a "how about
doing it this way---isn't it cleaner?" suggestion to your code patch, you
at least owe either "yeah, that looks better---thanks, I've used it in
this reroll" or "no, because...; I've used the original" to the person who
tried to help you, no?
I completely agree -- all of Michael's suggestions were excellent, and
I'd definitely owe him an explanation for not using something. In
this particular case, it was an honest mistake though- I meant to
include Michael's version, but I'd rolled out the wrong commit after
rebasing.
-- Ram
From: Michael J Gruber <hidden> Date: 2016-06-15 22:51:00
Ramkumar Ramachandra venit, vidit, dixit 06.04.2011 20:09:
Hi Junio,
Junio C Hamano writes:
quoted
Ramkumar Ramachandra [off-list ref] writes:
quoted
I'm very sorry to have caused so much pain. Yes, I can imagine how
terrible it must be to review several iterations of a simple
documentation patch. Thank you for being so patient with me so far- I
understand if you don't want to do this anymore.
I do spend time proofreading patches before sending them out, but I'm
clearly not very good at it. In future, I'll either try rewriting
entire paragraphs or simply refrain from writing documentation patches.
I do not think that is the lesson you should learn from this exchange. A
major part of Michael's complaint (which I think was justified) was that
he even made a suggestion that is ready to be cut-and-pasted, but your
reroll does not use the suggested phrasing _without_ explaining why it
doesn't.
It is not limited to "documentation patches". If you get a "how about
doing it this way---isn't it cleaner?" suggestion to your code patch, you
at least owe either "yeah, that looks better---thanks, I've used it in
this reroll" or "no, because...; I've used the original" to the person who
tried to help you, no?
I completely agree -- all of Michael's suggestions were excellent, and
I'd definitely owe him an explanation for not using something. In
this particular case, it was an honest mistake though- I meant to
include Michael's version, but I'd rolled out the wrong commit after
rebasing.
Ram, all is well (explained) now, and please don't give up on
documentation patches. You see, it happened to me again and again that I
submitted something, and someone took over the initiative or the idea
and submitted something under his name. And that is completely OK (after
all I had signed off on my patch, it's part of the O in OSS) but
"deprives" the original submitter of the "reward" of having the commit
count incremented. And that is what I wanted to spare you by not
submitting my own version.
Cheers,
Michael
Ramkumar Ramachandra venit, vidit, dixit 06.04.2011 20:09:
quoted
Junio C Hamano writes:
quoted
Ramkumar Ramachandra [off-list ref] writes:
quoted
I'm very sorry to have caused so much pain. Yes, I can imagine how
terrible it must be to review several iterations of a simple
documentation patch. Thank you for being so patient with me so far- I
understand if you don't want to do this anymore.
I do spend time proofreading patches before sending them out, but I'm
clearly not very good at it. In future, I'll either try rewriting
entire paragraphs or simply refrain from writing documentation patches.
I do not think that is the lesson you should learn from this exchange. A
major part of Michael's complaint (which I think was justified) was that
he even made a suggestion that is ready to be cut-and-pasted, but your
reroll does not use the suggested phrasing _without_ explaining why it
doesn't.
It is not limited to "documentation patches". If you get a "how about
doing it this way---isn't it cleaner?" suggestion to your code patch, you
at least owe either "yeah, that looks better---thanks, I've used it in
this reroll" or "no, because...; I've used the original" to the person who
tried to help you, no?
I completely agree -- all of Michael's suggestions were excellent, and
I'd definitely owe him an explanation for not using something. In
this particular case, it was an honest mistake though- I meant to
include Michael's version, but I'd rolled out the wrong commit after
rebasing.
Ram, all is well (explained) now, and please don't give up on
documentation patches. You see, it happened to me again and again that I
submitted something, and someone took over the initiative or the idea
and submitted something under his name. And that is completely OK (after
all I had signed off on my patch, it's part of the O in OSS) but
"deprives" the original submitter of the "reward" of having the commit
count incremented. And that is what I wanted to spare you by not
submitting my own version.
Cool, thanks for understanding and bearing with my slopiness :p
Yes, I strongly believe that we should spend time writing reviews,
even if it's quicker to redo the series entirely* -- that's how we can
get more contributors :)
* This is often the case with inexperienced contributors
-- Ram