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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
