Re: [libreoffice-projects] [ANN] Please use Gerrit from now on for Patch Review

Hi Petr, all,

i am using gerrit for a while now and gathered some experience with it 
already and would like
to share it with you.

On 19.06.2012 19:24, Petr Mladek wrote:
> Bjoern Michaelsen píše v Út 19. 06. 2012 v 18:40 +0200:
> > Hi Petr,
> >
> > On Tue, Jun 19, 2012 at 06:14:18PM +0200, Petr Mladek wrote:
> > > Ah, this bug is about a daily digest. I think that we first need to
> > > decide how much we want to modify the current work flow. Do we want to
> > > really move most discussions from the mailing list to gerrit?
> > IMHO yes, they are noise on the mailing list as you need deep context to follow
> > them. In gerrit you can even comment inline in the patch.
> Sounds good but how many people would know about the comments? How hard
> would be to find them?
https://gerrit.libreoffice.org/#/c/179/4/
(may be you need to login into gerrit with your openId)
You can see it immediatelly: if and how much and for wich file exactly.

For me this is one of the most valuable features of gerrit: inline comments.
On comment column from 17 files Michael has commented in 5 files.
This is already really good, isnt't? But it going to be even better:
the submitter can respond (and he surely will, if he doesn't understand 
what the reviewer meant):
in the context of this file/line.

Still not convinced? How about this:
12 comments from different peoples on only one line?
https://gerrit-review.googlesource.com/#/c/35380/3/gerrit-server/src/main/java/com/google/gerrit/server/project/ListProjects.java

You can try to simulate this flow in mail with patch(es)...

> > > How people will be noticed about news in gerrit?
> > Reporters and Reviewer will get mails about "their" patches. Unless they prefer
> > a different workflow in which case they can change their preferences. A lot
> > better than what we have now.
> Sure but who will be the reviewer?
In my case (gbuild'ification of dmake module) the usual suspects are
Stefan, David Tardon, Michael Stahl, Matus and Björn.
;-)
I guess every LO-area has their own specalists.

> The mailing list has the advantage that people step in when they are interested.
I agree with you as far as globally interested topics are discussed.
But with my (build specific) questions only build experts were able to help.
But then the context was wrong anyway: Mail to ML with [GERRIT] in topic 
or [PATCH] for that matter and reall special questions in the body,
like how to fix broken pyuno bridge on mingw platform (because no python 
is currently get packaging in the installation set there).
Those mail created noise on the ML, but those two people who answered 
were already on the CC list in the mentioned gerrit patch.
So I would better just commented something there (inline) and they would 
be notify anyway and respond to me (without noise) and in the context of 
this gerrit patch.

Another most valuable gerrit feature for me is the preserving of patch 
history (many change sets on gerrit) and still having only one
commit in the real repository. This magic is achived through the 
combination of ChangeId git hook,
git rebase -i command and gerrit's handling of ChangeId as the context 
of gerrit patch.

This flow may be not so obvious:

git commit # some changes (git ChangeId hook generate a fresh ChangeId)
git push logerrit HEAD:refs/for/master # gerrit patch with first change 
set is created.
git commit # further changes
git rebase -i HEAD~2 # with fixup preserves the same ChangeId
git push logerrit HEAD:refs/for/master # second change set in the same 
(!) gerrit patch is created (same ChangeId)

And the best is: you can see the evolution of the patch (with command 
line tool, gerrit web interface or gitweb/cgit).

I got one question with gerrit so far:
how can other people contribute code snippet into foreign gerrit patch 
(so called extend it)?
During my work on gbuildi'fication of pyuno module Stefan helped me with 
some scp2, Windows and Mac OS X specific stuff.
But he can not put a change set into my gerrit patch.
So he created a couple of patches and sent it to ML, I applied the 
patches and pushed the next iteration to gerrit.
While is was working, this flow obviously violates the common repository 
rule: every contribution should hit repository with the name of the 
right contributor.
Sure we could create a new integration branch, like lately gbuild_merge 
branch and push our own gerrit patches there...
Ideas on this?

Regards
David