Jeff King [off-list ref] writes:
... We do not have an explicit code of
conduct on the list, but it is not as if behavior is without
consequences. If you are not easy to work with, people will get tired of
dealing with you eventually[1].
FWIW, I have already reached that point and learned to kill certain
types of threads in my MUA. There is no point wasting time arguing,
rather than tending to patches from other people.
One example of killing the entire thread is when I see "This patch
will not be applied" by Felipe in a thread started with his patch.
I understand that it is his way to say "this patch is retracted"
without having to explicitly say that he now understands that
reviews showed why the patch was wrong or that he thanks the
reviewer for enlightening him.
The patch will come back, with corrections as necessary, if it has
merit, so we do not lose anything of value anyway by discarding the
thread.
On Sun, Jun 9, 2013 at 4:39 PM, Junio C Hamano [off-list ref] wrote:
One example of killing the entire thread is when I see "This patch
will not be applied" by Felipe in a thread started with his patch.
I understand that it is his way to say "this patch is retracted"
without having to explicitly say that he now understands that
reviews showed why the patch was wrong or that he thanks the
reviewer for enlightening him.
You are wrong. There's nothing wrong with the patch.
The patch will come back, with corrections as necessary, if it has
merit, so we do not lose anything of value anyway by discarding the
thread.
Wrong again. It seems nobody is interested in improving 'git rebase',
specially not to reduce the number of forks, and use C code instead
(git cherry-pick). Instead, people want to complain about the number
of forks, but not lift a finger about it, not even to review patches.
Good luck getting them to actually do something about it.
But thanks for letting me know, I'm dropping right now this series of
perfectly good 36 patches that move us forward towards our ideal; more
C code, less script code, improves 'git cherry-pick', simplifies and
fixes 'git rebase', and makes it more consistent.
I thought you understood that code should speak, but apparently you don't.
--
Felipe Contreras