Open Stack

On Mon, Nov 9, 2015 at 2:03 PM James E. Blair <corvus at inaugust.com> wrote:

> 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.
>
>
Slide decks for many of the presentations are online at the Summit webpage:

https://gerrit.googlesource.com/summit/2015/+/master/index.md



> --==--
>
> 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.
>
>
Have a look at this change to see how it was done:

https://gerrit-review.googlesource.com/#/c/63812/

--==--
Note that all of the features mentioned below will be in 2.12, not 2.11.x.



> * 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).
>
>
We're looking into the possibility of enabling only enough of the notedb to
make hashtags work in 2.12.



> --==--
>
> 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
>
> _______________________________________________
> OpenStack-Infra mailing list
> OpenStack-Infra at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20151110/33f7a337/attachment-0001.html>