Open Stack

Khai Do and I attended the Gerrit User Summit this weekend.  It was a
very busy weekend indeed with quite a lot of activity in all areas
related to Gerrit.  The following is a brief summary of items which
may be of interest to our community.

--==--

David Pursehouse from Sony Mobile spoke about what's new in 2.11 and
coming in 2.12:

* Inline editor.  There will be an inline editor so that edits to
  commits can be made through the web interface.

* Better file sorting for C/C++ (headers listed before source).  We
  may want to look into the mechanism used for this to see if it can
  be applied to other situations, such as listing test files before or
  after implementation.

* Submit changes with ancestors.  When the tip of a branch is
  submitted and all of its ancestors are submittable, they will all be
  submitted together.  If ancestors are not submittable, the change at
  the tip will not be submittable.  This removes the submit queue and
  the "Submitted, merge pending" state from Gerrit and generally makes
  submission an immediate atomic operation.  This is an improvement
  that will make several edge cases we encounter simpler, however,
  because Zuul handles submission and does so using strict ordering,
  this change will mostly be invisible in the OpenStack environment.

* Submit whole topic.  This is an implementation of the much-requested
  feature to merge changes to multiple repositories simultaneously.

  This uses the "topic" field to designate changes that should be
  merged simultaneously.  When this feature is enabled, the only
  "submit" option for a change which shares a topic with other changes
  will be "Submit whole topic".  There is a panel on the change screen
  that indicates which changes will be submitted together with the
  current one.  There was some discussion that this limits options --
  a user may not want to submit all changes on a topic at once, and
  unrelated changes may inadvertently end up sharing a topic,
  especially in busy systems or if a poor topic name is chosen (eg
  "test"), and that it formalizes one particular use of the "topic"
  field which to this point has been more free-form.  The authors are
  interested in getting an early version of this out for feedback, but
  acknowledge they have not considered all use-cases yet and may need
  to revise it.

  In the OpenStack community, we have decided to avoid pursuing this
  kind of feature because the alternative -- strict sequencing of
  co-dependent changes -- provides for better upgrade code and is more
  friendly to continuous deployers.  This feature can be disabled, so
  I anticipate we would do so and we would notice no substantial
  changes because of this.  Of course, if we want to revisit our
  decision, we could do so.

* Option to require all commits pushed be GPG signed.

* Search by author or committer.  Also, search by comment author.

* As noted in another recent thread by Khai, the hashtags support
  (user-defined tags applied to changes) exists but depends on notedb
  which is not ready for use yet (targeted for 3.0 which is probably
  at least 6 months off).

--==--

Shane McIntosh from McGill University presented an overview of his
research into the efficacy of code review.  The data he studied
include several open source projects including OpenStack.  His
papers[1] are online, but some quick highlights from his research:

* Modules with a high percentage of review-focused developers are less
  likely to be defective.
* There is a sweet spot around two reviewers, where more reviewers are
  less likely to find more defects.

And some tidbits from other researchers:

* Older code is less defect prone (Graves, et al, TSE 2000)
* Code with weak ownership is more defect prone (Bird, et al,
  ESEC/FSE 2011)

[1] http://shanemcintosh.org/tags/code-review.html

--==--

There were a litany of presentations about Gerrit installations.  I
believe we may be one of the larger public Gerrit users, but we are
not even remotely near the large end of the scale when private
installations are considered.  Very large installations can be run on
a single large instance.  Many users are able to use a master-slave
configuration to spread load.  Perhaps only Google is running a
multi-master system, though they utilize secret Google-only
technology.  It is possible, likely even with open-source components,
but would require substantial customized code.  It is likely that the
notedb work in Gerrit 3.0 will simplify this.

--==--

I gave a short presentation on Gertty.  The authors of the Gerrit REST
API were happy to see that it could support something like Gertty.

--==--

Johannes Nicolai of CollabNet presented a framework for tuning Gerrit
parameters, and produced a handout[2] as a guideline.

It was noted that the Gerrit documentation recommends disabling
connection pooling with MySQL.  This is apparently because of bad
experiences with the MySQL server dropping idle connections.  Since we
have addressed this issue in OpenStack, this might be an opportunity
for us to improve the Gerrit documentation around MySQL.

[2] http://bit.ly/1kmpO7V

--==--

Dave Borowitz from Google spoke about NoteDB.

NoteDB is the name of the effort to move all change metadata out of a
relational database and into git.  It is expected to be the defining
feature of Gerrit 3.0.  It is also poorly named and they would love to
rename it.

Reviews will be stored in commits pointed to by special refs such as
refs/changes/34/1234/meta.  The text of the commit message will be a
human and machine parse-able representation of the review message and
votes.  The files within that commit will contain the inline comments
associated with the review, in a similarly parse-able format.

Non-change entities (accounts, groups, etc) will also be represented
in git (likely in the special All-Projects git repo).

Future enhancements (more likely after the initial 3.0 release) may
include federation -- transferring a change and its review history to
another Gerrit server is a simple git fetch, improved support for
offline code review, and potentially interoperation with other code
review systems (such as github or phabricator) if their operators can
agree on a basic format for what a "code review" looks like.

Partial NoteDB support for changes exists in the current Gerrit master
branch, though it is disabled by default.  Soon they will ask
volunteers to turn on write support -- so that all operations write to
both the database and git, but data are only read from the database --
to help identify real-world performance problems before release.  This
feature will also be able to support a zero-downtime migration.

--==--

Luca Milanesio of GerritForge spoke about packaging Gerrit.

He provides rpm and deb packages of Gerrit, as well as Docker images.
He also builds all of the available Gerrit plugins and has a system
for managing their installation.  He thanked Khai for suggesting our
own Jenkins Job Builder to drive the templated Jenkins configuration
he uses to build the plugins.

--==--

Dave Borowitz of Google spoke about work from Andy Bons on PolyGerrit,
the new Gerrit UI.

Everyone recognizes the UI and UX challenges with Gerrit, but because
the current web interface is built on GWT, it has been difficult to
get UX specialists interested in improving it.

Polymer is a web framework that is being used to produce a new user
interface for Gerrit.  Notably, it compiles to apparently simple
static HTML files -- no more "#" needed in URLs.  The current
implementation is already able to display a basic change screen,
change lists, and side-by-side diffs.  The initial target of the work
is to more-or-less reproduce the "new" change screen, drop the GWT
interface, then iterate with specialists to improve the UX.

--==--

That is a quick summary of the high points -- if you would like any
more details, feel free to ask Khai or I and we may be able to provide
them.

-Jim