On Mon, Nov 9, 2015 at 2:03 PM James E. Blair <[email protected]> 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 > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
