Gerrit FAQ : Why gerrit and other considerations....

ok so it seems clear than more explanations are needed.

First, Why Gerrit, the FAQ:

Q: What is Gerrit ?
R: Gerrit is a code review system, tightly integrated with git.

Q: What do we expect to achieve with Gerrit ?
R: There are multiple objective, in no particular order

a/ Allow dev to pre-build commit on a variety of platform _before_
pushing them to master. iow check and push rather than the current
push and fix. (and yes there are way to do that in a 'feature/branch'
kind of way)

b/ The fact that commit can be tested on their own, means that the
neeed for the 'fastest' possible tinderbox is much less important.
Today the reason speed is such a premium for these box is to avoid the
'domino' effect: someone push something that happen to break master...
the long it takes the more other patch accumulate on a 'red' box, each
of them has a chance to also break the build, but is less noticed
because the breakage is hidden by the previous breakage... the list of
people notified is getting longer and longer, and as a consequences
people assume more and more that it must be someone else''s bug. This
phenomena was very obvious when the Windows build was taking 4 to 6
hours... windows spent days and weeks ina  row in red... until a brave
soul talked the thankless job of sorting all that out.
With the gerrit model, the time to do a build is less important, and
therefore even not-so-fast machine can be put to good use. Iow it
scales better. Furthermore the granularity of the result is much more
narrow and the nagging much more targeted.

c/ Gerrit has a very nice interface for interaction between dev,
especially it allows reviewer to concisely state their remarks
directly inline with the patch. it also allow the dev to trivially
push a 'new version' of a given change. This make reviewing code much
more practical... and given how hard it is to get Reviewer time, the
easiest it is for the reviewer the better.

d/ It should be possible to semi-automate the application of patch
submitted to the ML, ideally forward a patch from the ML to a
dedicated mailbox -> the patch show up in gerrit... then
review/verify/submit the change.. or ping someone else if the person
that scrubed the patch from the ML is not confident enough to 'commit'
it

e/ Make the simple/triple review mechanism for release branch trivial:
push a commit /for/<release-branch> and reviewer can just do +1
there... the reviewer that give the last necessary review just put +2
and click 'publish and submit' the change.

f/ Gerrit as a powerful query command line which would allow for
convenient, customized way to query change that get in. For example
one could query to find all the changes that impact a given set of
files, which would allow de-facto module maintainer to keep an eye on
proposed change in their are of expertise... but that is just one
example... Pretty much everything that can be done using the web
interface can be done using command line... heck one could even write
an emacs-mode front-end to gerrit... The plumbing is there, so if you
do not like the web-porcelain, you can write your own.

Q: What is the workflow with gerrit ?
R: That is the big question, and that is why we asked you to 'play'
with gerrit... The exact workflow, how far do we go with it are
questions that require dev with different habits and requirement to
tell us what is working for them and what is painful. With such
feedback we can 1/ improve the tooling 2/ adjust the workflow 3/
improve the documentation. Like everything else it won't be perfect
for everything to everyone, but with feedback we can at least try to
find the best compromise.

Q: When will it be for 'real'
R: IF it is adopted, then getting in production will require few step.
1/ the migration to submodule need to happen, to make the most of the
buildbot-testing abilities
2/ the OpenID kink should be ironed-out. Ideally we should have a TDF
hosted OpenID solution
3/ Every committer need to be registered in gerrit and placed in the
appropriate group
4/ Doc for newbies and for more advanced user need to be written, that
also cover the need for 'good practices' and 'sensible naming
convention'.
5/ When the time come, turn fdo to read-only, gerrit become the
primary git source (note that we could do that today without changing
anything to the current workflow)
So it will reasonably be 2-3 month at best.

Depending on the workflow selected for the different ways to get code
into the repos, there will be the need to develop some tooling to
limit the number of false negative for the buildbots (if someone where
to push a broken commit directly to master, every 'for review' patch
built on top of that borked master would return a Verify = -1 status
doe to a build failure that is not related to the commit under
review... weeding out these would require a database of build commit
with a 'status' to be able to be smart and have a Verify +0 return
from the tinbuild or even delay test-building a patch that is based on
a broken master until that patch is rebased on a green 'base'...
anyway that level of sophistication is not mandatory to go to production.


Second, Why should you care, and why should you spend time
testing/experimenting with it ?

We will eventually switch the fdo git repo to read-only, which means
that you will need to be registered in gerrit and put in the Committer
Group there to be able to continue to push commits directly to master,
and for that matter to do anything but 'read' the repos.

By experimenting with it, you can help us discover the kinks,
pain-points or holes in the process. It is much easier to address
these over some time while we can still make big changes without too
much impact, rather than try to change on the fly a live production
system.

Norbert