On Friday, 24 October 2014 01:05:23 CEST, Thomas Lübking wrote:
Errm... on the gerrit process:
First of all, the original patch in Gerrit is not mine, it was contributed
by Luke-Jr on IRC. IIRC I haven't asked for an upload to Gerrit, I wasn't
completely sober at that point :), so I simply uploaded his work later next
day.
how would this case be dealt (patch to a patch in review)?
Can I just push into your review (and more important: would you
be pissed if I did? ;-)
Should one open a competing patch instead?
Or is there any canonical collaboration process in gerrit?
If this was a small change, similar to how I changed the original patch
based on your review, then I think that simply "replacing" the commit in
Gerrit is a correct thing to do. This is done by downloading the change
locally, amending the commit in any way that is needed, and pushing it back
to refs/for/master. The only important thing is to make sure that the
Change-Id is preserved; your new commit will become a next iteration or
verson of the change. This is also good for fixing small mistakes, etc.
If the original change is not perfect, but works on its own, then one can
upload a followup change. This is done by checking out the original change
and placing another commit as a child of the old one. Gerrit will make sure
that the new change won't be submitted until the original one is approved
and merged. I think that this is a reasonable approach in this situation --
essentially multiple people are creating a patch series which works towards
a certain goal. This approach should not be used when the previous commit
introduces some fatal regression, though, such as build failure or a test
failure -- doing that would make bisecting a nightmare.
Finally, if the original change was completely wrong, then it would make
sense to abandon it and upload an independent replacement, but that's not
the case here.
Cheers,
Jan
--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
