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 _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice