<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Mon, Nov 9, 2015 at 2:03 PM James E. Blair <<a href="mailto:corvus@inaugust.com">corvus@inaugust.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Khai Do and I attended the Gerrit User Summit this weekend.  It was a<br>
very busy weekend indeed with quite a lot of activity in all areas<br>
related to Gerrit.  The following is a brief summary of items which<br>
may be of interest to our community.<br>
<br></blockquote><div><br></div><div>Slide decks for many of the presentations are online at the Summit webpage:</div><div><br></div><div><a href="https://gerrit.googlesource.com/summit/2015/+/master/index.md">https://gerrit.googlesource.com/summit/2015/+/master/index.md</a><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
--==--<br>
<br>
David Pursehouse from Sony Mobile spoke about what's new in 2.11 and<br>
coming in 2.12:<br>
<br>
* Inline editor.  There will be an inline editor so that edits to<br>
  commits can be made through the web interface.<br>
<br>
* Better file sorting for C/C++ (headers listed before source).  We<br>
  may want to look into the mechanism used for this to see if it can<br>
  be applied to other situations, such as listing test files before or<br>
  after implementation.<br>
<br></blockquote><div><br></div><div>Have a look at this change to see how it was done:</div><div><br></div><div><a href="https://gerrit-review.googlesource.com/#/c/63812/">https://gerrit-review.googlesource.com/#/c/63812/</a><br></div><div><br></div><div>--==--</div><div>Note that all of the features mentioned below will be in 2.12, not 2.11.x.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* Submit changes with ancestors.  When the tip of a branch is<br>
  submitted and all of its ancestors are submittable, they will all be<br>
  submitted together.  If ancestors are not submittable, the change at<br>
  the tip will not be submittable.  This removes the submit queue and<br>
  the "Submitted, merge pending" state from Gerrit and generally makes<br>
  submission an immediate atomic operation.  This is an improvement<br>
  that will make several edge cases we encounter simpler, however,<br>
  because Zuul handles submission and does so using strict ordering,<br>
  this change will mostly be invisible in the OpenStack environment.<br>
<br>
* Submit whole topic.  This is an implementation of the much-requested<br>
  feature to merge changes to multiple repositories simultaneously.<br>
<br>
  This uses the "topic" field to designate changes that should be<br>
  merged simultaneously.  When this feature is enabled, the only<br>
  "submit" option for a change which shares a topic with other changes<br>
  will be "Submit whole topic".  There is a panel on the change screen<br>
  that indicates which changes will be submitted together with the<br>
  current one.  There was some discussion that this limits options --<br>
  a user may not want to submit all changes on a topic at once, and<br>
  unrelated changes may inadvertently end up sharing a topic,<br>
  especially in busy systems or if a poor topic name is chosen (eg<br>
  "test"), and that it formalizes one particular use of the "topic"<br>
  field which to this point has been more free-form.  The authors are<br>
  interested in getting an early version of this out for feedback, but<br>
  acknowledge they have not considered all use-cases yet and may need<br>
  to revise it.<br>
<br>
  In the OpenStack community, we have decided to avoid pursuing this<br>
  kind of feature because the alternative -- strict sequencing of<br>
  co-dependent changes -- provides for better upgrade code and is more<br>
  friendly to continuous deployers.  This feature can be disabled, so<br>
  I anticipate we would do so and we would notice no substantial<br>
  changes because of this.  Of course, if we want to revisit our<br>
  decision, we could do so.<br>
<br>
* Option to require all commits pushed be GPG signed.<br>
<br>
* Search by author or committer.  Also, search by comment author.<br>
<br>
* As noted in another recent thread by Khai, the hashtags support<br>
  (user-defined tags applied to changes) exists but depends on notedb<br>
  which is not ready for use yet (targeted for 3.0 which is probably<br>
  at least 6 months off).<br>
<br></blockquote><div><br></div><div>We're looking into the possibility of enabling only enough of the notedb to make hashtags work in 2.12.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
--==--<br>
<br>
Shane McIntosh from McGill University presented an overview of his<br>
research into the efficacy of code review.  The data he studied<br>
include several open source projects including OpenStack.  His<br>
papers[1] are online, but some quick highlights from his research:<br>
<br>
* Modules with a high percentage of review-focused developers are less<br>
  likely to be defective.<br>
* There is a sweet spot around two reviewers, where more reviewers are<br>
  less likely to find more defects.<br>
<br>
And some tidbits from other researchers:<br>
<br>
* Older code is less defect prone (Graves, et al, TSE 2000)<br>
* Code with weak ownership is more defect prone (Bird, et al,<br>
  ESEC/FSE 2011)<br>
<br>
[1] <a href="http://shanemcintosh.org/tags/code-review.html" rel="noreferrer" target="_blank">http://shanemcintosh.org/tags/code-review.html</a><br>
<br>
--==--<br>
<br>
There were a litany of presentations about Gerrit installations.  I<br>
believe we may be one of the larger public Gerrit users, but we are<br>
not even remotely near the large end of the scale when private<br>
installations are considered.  Very large installations can be run on<br>
a single large instance.  Many users are able to use a master-slave<br>
configuration to spread load.  Perhaps only Google is running a<br>
multi-master system, though they utilize secret Google-only<br>
technology.  It is possible, likely even with open-source components,<br>
but would require substantial customized code.  It is likely that the<br>
notedb work in Gerrit 3.0 will simplify this.<br>
<br>
--==--<br>
<br>
I gave a short presentation on Gertty.  The authors of the Gerrit REST<br>
API were happy to see that it could support something like Gertty.<br>
<br>
--==--<br>
<br>
Johannes Nicolai of CollabNet presented a framework for tuning Gerrit<br>
parameters, and produced a handout[2] as a guideline.<br>
<br>
It was noted that the Gerrit documentation recommends disabling<br>
connection pooling with MySQL.  This is apparently because of bad<br>
experiences with the MySQL server dropping idle connections.  Since we<br>
have addressed this issue in OpenStack, this might be an opportunity<br>
for us to improve the Gerrit documentation around MySQL.<br>
<br>
[2] <a href="http://bit.ly/1kmpO7V" rel="noreferrer" target="_blank">http://bit.ly/1kmpO7V</a><br>
<br>
--==--<br>
<br>
Dave Borowitz from Google spoke about NoteDB.<br>
<br>
NoteDB is the name of the effort to move all change metadata out of a<br>
relational database and into git.  It is expected to be the defining<br>
feature of Gerrit 3.0.  It is also poorly named and they would love to<br>
rename it.<br>
<br>
Reviews will be stored in commits pointed to by special refs such as<br>
refs/changes/34/1234/meta.  The text of the commit message will be a<br>
human and machine parse-able representation of the review message and<br>
votes.  The files within that commit will contain the inline comments<br>
associated with the review, in a similarly parse-able format.<br>
<br>
Non-change entities (accounts, groups, etc) will also be represented<br>
in git (likely in the special All-Projects git repo).<br>
<br>
Future enhancements (more likely after the initial 3.0 release) may<br>
include federation -- transferring a change and its review history to<br>
another Gerrit server is a simple git fetch, improved support for<br>
offline code review, and potentially interoperation with other code<br>
review systems (such as github or phabricator) if their operators can<br>
agree on a basic format for what a "code review" looks like.<br>
<br>
Partial NoteDB support for changes exists in the current Gerrit master<br>
branch, though it is disabled by default.  Soon they will ask<br>
volunteers to turn on write support -- so that all operations write to<br>
both the database and git, but data are only read from the database --<br>
to help identify real-world performance problems before release.  This<br>
feature will also be able to support a zero-downtime migration.<br>
<br>
--==--<br>
<br>
Luca Milanesio of GerritForge spoke about packaging Gerrit.<br>
<br>
He provides rpm and deb packages of Gerrit, as well as Docker images.<br>
He also builds all of the available Gerrit plugins and has a system<br>
for managing their installation.  He thanked Khai for suggesting our<br>
own Jenkins Job Builder to drive the templated Jenkins configuration<br>
he uses to build the plugins.<br>
<br>
--==--<br>
<br>
Dave Borowitz of Google spoke about work from Andy Bons on PolyGerrit,<br>
the new Gerrit UI.<br>
<br>
Everyone recognizes the UI and UX challenges with Gerrit, but because<br>
the current web interface is built on GWT, it has been difficult to<br>
get UX specialists interested in improving it.<br>
<br>
Polymer is a web framework that is being used to produce a new user<br>
interface for Gerrit.  Notably, it compiles to apparently simple<br>
static HTML files -- no more "#" needed in URLs.  The current<br>
implementation is already able to display a basic change screen,<br>
change lists, and side-by-side diffs.  The initial target of the work<br>
is to more-or-less reproduce the "new" change screen, drop the GWT<br>
interface, then iterate with specialists to improve the UX.<br>
<br>
--==--<br>
<br>
That is a quick summary of the high points -- if you would like any<br>
more details, feel free to ask Khai or I and we may be able to provide<br>
them.<br>
<br>
-Jim<br>
<br>
_______________________________________________<br>
OpenStack-Infra mailing list<br>
<a href="mailto:OpenStack-Infra@lists.openstack.org" target="_blank">OpenStack-Infra@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra</a><br>
</blockquote></div></div>