gerrit for release branches (bots ftw?)

[Petr Mladek]

Bjoern Michaelsen píše v Po 18. 06. 2012 v 15:27 +0200:
> Hi all,
> 
> reviewing patches for a release branch is currently a hassle:

I see the main advantages of gerrit in the following three things:

	+ be able to check build on more platforms before pushing;
          useful for more complex changes
	+ buildability is already tested when I start reviewing patch
	  => be more sure when approving trivial changes even for
                   branches where I do not have local build
	+ have nice overview of not-yet handled patches:
		+ be sure that all patches are committed before release
		+ do not miss contributed patches

Though, there are other solutions for the above advantages:
	+ tinderboxes could build branches
	+ we have less build breakages last months
	+ making sure that all patches are integrated affects primary
          only one person (me :-)
	+ IMHO, we do not miss too many patches; also people could ask
          again; they need to be patient and a bit motivated to be able
          to work on LO anyway

We need to be sure that advantages are bigger than disadvantages.
We need to make sure that all processes are either easier or not too
much more complicated. I am not convinced yet, see below.


> submitter:
> - find cgit link
> - write to mailing list with cgit link asking for review

This handles only people with commit access and review for stable
branches. It does not handle newbies.


> reviewer:
> - check out the release branch
> - cherrypick commit on release branch by exctracting the commit-id from the cgit link
> - review the commit
> - push commit on the release branch
> - mail to list that the stuff is pushed
> 
> using gerrit its a bit simpler for the reviewer:
> - check out the release branch
> - gerrit-cherry-pick the commit
> - push the commit to the release branch (gerrit will take care of notifying the submitter

Hmm, this is not much encouraging:

	+ "git push" is easy.
	+ if there are conflict, who and how would resolve them in
          gerrit?
	+ you need to write a comment when approving the change anyway;
          some more words might motive the volunteer to come again, so
          the gerrit tool might be rather antisocial


> but the submitter has a bit more to do:
> - check out the release branch
> - cherry-pick the commit
> - push to refs/for/libreoffice-3-5

This is even worse. We rather need to lower the barriers and make things
easier.


> While that is rather simple, it could be scripted even simpler. I submitted a bug to gerrit wrt this:
> 
>  http://code.google.com/p/gerrit/issues/detail?id=1446
> 
> but maybe I am just overlooking a best practice there.

The command is too long. I am afraid that you need to come up with
something easier to get it adopted.


>  If not, we might
> alternatively have either a email or an IRC bot, which you send a message like:
> 
>  releasereview 213d5355d78a0a690e366645d6416f4a8fe5e666 libroffice-3-5
> 
> and it will do all of the above on its own. Opinions on that? Is it better to
> have an IRC or an Email bot?

This looks better. It similar to the message from the openSUSE Build
Service that I attached to the other mail.

I prefer mail. irc is too distracting because it forces you to stop an
action and solve the other problem immediately. I am getting very
nervous when the stack of interruptions is more than 4. Also people need
to sleep some time and irc is still rolling.

I still see it optimistic. I am just not happy with the style of pushing
this solution. You direct style brought strong offense from others. It
brought offense from you as well. For me, it is harder to be
constructive in this atmosphere. I would prefer if you motivate people
rather than scary them. Also, you should hear their needs and offer
solutions. If you are not sure about their needs, you should ask for
more details.

Thanks in advance for patience ;-)


Best Regards,
Petr