London to host Gerrit User Summit 2017

gerritusersummit-2017-poll-results.png

… and the winner is … Europe/London!

Despite the future Brexit plans, London will still be this year the beating heart of Code Review innovation by hosting the Gerrit User Summit 2017.

Here are the numbers in detail:

  • 157 people visited the poll page (goo.gl/M7X6rp)
  • 75 people from 14 countries expressed their vote in the past two weeks
  • Summit in Europe (only Europe + USA/Europe) received 54 votes
  • Summit in USA (only USA + USA/Europe) received 37 votes

Countries

GerritUserSummit2017-countries.png

The audience is very diverse, with the most votes coming from West and East Coast of the USA, the British Isles, and Germany. There was some interest in the Summit as well from Israel, India, and Japan.

It will be excellent to see new faces at this year Gerrit User Summit, to exchange ideas and capture new and essential requirements for the next versions to come.

The London Venue and Dates

SkillsMatter.png

SkillsMatter offered the CodeNode venue in London (10 South Place, London, EC2M 7EB, GB) which is entirely dedicated to hosting events, meetups and user groups from the global OpenSource Community.

The new venue can record every session, open policy about taking pictures and share content and the possibility of streaming the event to allow remote attendees to watch and interact.

The proposed dates for the event are:

  • Saturday 30/09 to Sunday 01/10 – Pre-summit and Gerrit+Plugins Hackathon
  • Monday 02/10 to Tuesday 03/10 – Gerrit User Summit

New location, same community, and format

Even though this year the country and location will be different from the past User Summits hosted by Google in Mountain View – CA, we want to keep the organization and format of the Summit exactly as it was before:

  • User-driven: focussed on sharing experiences and networking between the users of Gerrit Code Review
  • Self-organized by the Community: no calls for papers, sponsored talks or products presentations. All has to come from the users and voted by the users.
  • No commercials: even though the supporters of the event are business entities (SkillsMatter, eSynergy, GerritForge and many others) we will be very careful in keeping the spotlight on the users and not interfere with them.

Costs and sponsorships

Historically Google has paid for all the costs involved in the Summits (venue, catering, marketing, etc.). For this year, a lot of companies who are using Gerrit Code Review and contributing to it have already provided their interest in contributing to cover the costs and make this European event successful.

We want to keep the list of sponsors small and tightly coupled with the Gerrit Community. If you are a company and you want to sponsor the event, please contact Luca Milanesio (luca@gerritforge.com) or post your offer to the Gerrit Code Review mailing list https://groups.google.com/forum/#!forum/repo-discuss.

Next steps

We will work together with the Gerrit Community to organize this event and make it fruitful and profitable for the future of this amazing OpenSource project.

Thanks again for your vote and your interest in the 2017 Summit.

Luca Milanesio – GerritForge

GerritHub.io powered by Polymer

polymer-logo

You can now use the Gerrit Code Review interface on GerritHub.io using the new Polymer-based UX. The code-name of the project is PolyGerrit.

Enabling Polymer is easy, just add “?polygerrit=1” to the regular GerritHub.io URL. or alternatively you can click on the  “PolyGerrit” link at the bottom of the GerritHub.io footer.

https://gerrithub.io/?polygerrit=1

Alternatively you can click on the  “PolyGerrit” link at the bottom of the GerritHub.io footer.

polygerrit-footer

What is Polymer and why it matters?

Polymer is a new type of library for the web, built on top of Web Components, and designed to leverage the evolving web platform on modern browsers. Differently from the traditional Gerrit GWT UX, Polymer is developed using  HTML and JavaScript and is supported and cached natively from your web browser.

Why is Gerrit moving away from GWT? Well, there are many reasons for steering direction:

  • Speed.
    With Web Components, the core building blocks of the UX are transferred once and then cached by the browser, giving a much faster and fluid user experience.
  • Multi-sized screen support.
    Web Components are “instructed” to be rendered differently on different devices, giving the best user experience and accessibility of the device’s form factor and native interactions.
  • Branding.
    By using native HTML and CSS rendering, it becomes much easier to control and customize the look and feel of Gerrit.
  • Stability.
    Web Components development allow focusing on basic building blocks that are straightforward and testable. It becomes much easier to develop much more stable and robust components.
  • Skills-set.
    Typically, web developers find themselves more comfortable in using a front-end language and have much more control of what gets generated, understood and rendered by the web browser.

GerritHub.io on mobile

One interesting feature of PolyGerrit is the mobile view of Gerrit UX.

polygerrit-on-mobile

Gerrit’s GWT interface has always been quite a challenge on small-screen devices, mainly because of the inability of being sensitive to the reorganization fo the page real estate based on the device’s form factor.

Additionally, the buttons did not have enough real estate needed for “big thumbs”.

The ability to use Polymer has opened up a wide range of possibilities of interactions and, for the first time, a real fully featured review experience “on the road”.

Big thumbs up for the new Gerrit Mobile UX !

What and when?

What is currently implemented in the new Gerrit Polymer-UX? Not much in terms of screens, but a lot of the core functionality of the Code Review: the changes list and the review panels. What is missing? All the other Gerrit screens more dedicated to the management of the platform and the account, the projects and groups listing, and all the support for the UX plugins.

The PolyGerrit project announced at the Gerrit User Summit 2016 last year that they are making good progress and expect to have the first “production-ready” release by Feb/Mar 2017. In the meantime, all the code is stable and the current screens are good enough to be used on a daily basis.

Do I still need the GWT UX?

Yes, at least for the functionality that isn’t available yet in PolyGerrit. To switch back to GWT, simply add “?polygerrit=0” to the target URL.

https://gerrithub.io/?polygerrit=0

Credits

Many thanks to the Google’s PolyGerrit Team, lead by Andrew Bonventre, which started the Polymer support for Gerrit UX. A special thank to David Ostrovsky, who implemented the Gerrit switcher support to enable to use both GWT-UI and PolyGerrit-UI at the same time.

Gerrit User Summit 2016 Report

gerritusersummit-2016-google

The 9th edition of the Gerrit User Summit has ended today: a lot of new features and ideas have been presented and experimented in those four days.
Here is a summary of what happened and a description of the main innovations and presentations at the Summit and Hackathon at GooglePlex in Mountain View – CA.

12th-13th of November – The Summit

Gerrit v2.13

David Pursehouse from CollabNet presented what is coming in Gerrit v2.12 and v2.13.
Gerrit v2.13 has been the biggest version of Gerrit ever, with over 2,600 commits from 83 different contributors. That shows that Gerrit is an OpenSource project with a growing Contributors’ Community, getting more diverse over time.

There have been a lot of new features and improvements introduced. The most significant and noteworthy features are …

Git LFS

Ability to store large files outside the Git repository to an externally pluggable repository, such as HDFS or AWS S3.

Gerrit Metrics

New extension point to extract in real-time the performance data of Gerrit’s internal activity and publish them externally to Graphite, ElasticSearch, JConsole or other similar graphing and monitoring tool.

Hooks

There is now the ability to replace the dated hook system with much more powerful in-process-plugins. Existing hooks are then still supported using the “hooks” core plugin. Gerrit is getting more modular and extensible.

Improved review of Merge Commits.

Gerrit can implement effective “merge-requests” lifecycle on top of regular code review. You can now create feature branches exactly as you do with GitHub or GitLab and then submit only the “merge request” as change for reconsideration.

What’s cooking in Gerrit v2.14

PolyGerrit

After eight years, Gerrit GUI needed a complete revamp and modernisation, to compete with all the other web-based Code-Review systems such as GitHub, GitLab, and BitBucket.

Google has allocated a brand new front-end Team, located in San Francisco, to redesign and implement a brand-new user experience. It is much more than a simple rewrite; it is a complete rethinking of how to get the most of your code review functionality with the optimal utilization of space.
The new UX will be more fluid and adaptable to different sized screens, including tablets and even smartphones. It will be then possible to give a usable GUI even when accessing Gerrit “on-the-road.”

Suggested Reviewers

Gerrit is getting smarter and, by using sophisticated heuristics, it can now understand and sort the suggestions of which are the people that are most likely to be interested in reviewing a change. Gerrit allows saving time in browsing for individuals and contributes to the accuracy of the reviews.

New HTML e-mails interaction with Code Reviews

Say goodbye to long ugly diffs in e-mails, and now you can generate nice and tidy e-mails where all the details are carefully formatted for achieving maximum clarity. Additionally, you will be even able to reply in-line to the comments received via e-mail and Gerrit will be able to capture the message back and insert the feedback as code-review messages into the code carefully.

Robot comments

CI and automated systems can contribute comments to the code, without spamming the overall review discussion flow. That contributes to a much cleaner user-interface.
Google uses automated code analysis tools such as Tricium and ShipShape to capture the most common mistakes in coding and event providing the corresponding suggested fixes. All this feedback will be captured and integrated with Gerrit in the change comments GUI. The Change’s author will then be able to review the suggested fix and apply it with a simple click.

The management of robot commits will be fully operational with the new PolyGerrit GUI.

ElasticSearch Indexes

Instead of using the local Lucene Index, Gerrit would use an external ElasticSearch cluster to achieve maximum scalability and share the index across multiple nodes. That is one of the cornerstone feature needed for a multi-master setup.

A lot of time has been spent in making sure that the ElasticSearch support was aligned with the current Lucene implementation, but unfortunately, it took until v2.14 to fill the gap. Still, there are parts of the index not yet implemented in ElasticSearch, such as the on-line reindexing. Hopefully, the v2.14 will see all those gaps resolved and enable a real multi-master shared index setup.

Atomicity with Change-Sets

Basavaraj Karadakal from Juniper Networks presented a real-life implementation of the “submit whole topic” into his organization. We always said that “topics” require some company-wide naming policy to avoid conflicts and unexpected behaviors: Juniper found the solution by introducing a new concept, the “changeset.”

The name isn’t new to people that have been in the SCM long enough to remember IBM Rational ClearCase. Interestingly Basavaraj used that term, possibly to facilitate the understanding and adoption into the company.

The idea behind change set is to have a single change review “leading” the topic submission, stored in a “tracking repository”. One can understand the list of changesets and their status by querying the “tracking repository”. This feature is fascinating because it allows obtaining a full list of “open topics” inside Gerrit, which isn’t currently available as “out of the box” feature.

The overall implementation of change sets is composed of a set of client wrapper scripts and server-side plugin to orchestrate the review status of the changeset based on the review status of each commit included.

We do foresee a lot of feedback in the community around changesets and topics: the discussion started a couple of years ago and everyone agreed that “something was missing” in the current Gerrit topic concept … possibly the “change sets” are the missing piece of the jigsaw to make the “submit whole topic” a feature ready for production use.

Pull Requests in Gerrit

Since v2.13, Gerrit allows full reviews of merge commits. However, the workflow isn’t visible:

  • create a feature branch feature/abc
  • commit changes directly to the feature/abc branch, without requesting any review
  • once the branch is ready for review, merge into its target branch locally and push the merge commit to refs/for/target-branch

Eryk Szymanski, CollabNet, has presented an alternative GUI to make this scenario, typical of GitLib, GitHub, and BitBucket, more accessible for novice users.

The new Pull-Request GUI is based on two components:

  1. REST API, different from Gerrit’s native ones
  2. Pull-Request GUI, not integrated with Gerrit’s GWT or PolyGerrit but available as components of CollabNet’s TeamForge product.

Gerrit Analytics

Luca Milanesio from GerritForge introduced two new plugins in Gerrit 2.14:

  • Kafka stream events: to consume stream events and send them to topics
  • Project analytics: to crunch data from Gerrit repositories to expose aggregated contributors statistics

The vision of Luca Milanesio, GerritForge, is splitting Gerrit statistics into three dimensions:

  • People. What is the list of contributors, maintainers, reviewers? What do they do, how often they commit and which ones are the most active influencers?
  • Projects. How repositories are evolving over time and space and what do they need moving forward regarding storage and performance?
  • Systems. How is Gerrit behaving concerning CPU, Memory, and Network utilization?

The correlation of the metrics collected in these three dimensions allows putting together the KPI that allows understanding better how Gerrit is used and how to improve its current and future performance.
Additionally, you could use them to reward and promote good practices of code-review and fuel continuous innovation across the teams.

In one sentence, Gerrit Analytics will allow to “uncover the hidden value of your Gerrit Code Reviews”.

Plugins for CI Systems

Martin Fick from Qualcomm Innovation Center gave an overview of three new plugins developed for use by CI systems: the batch, manifest, and task plugins, with some modifications to the Gerrit core needed.

The batch plugin provides a mechanism for building and previewing sets of proposed updates to multiple projects/branches/refs that should be applied together. The focus of batch updates tends to be verification (by CI systems). The batch update service provides the tools to build refs by merging changes to temporary “snapshot” refs, which can then be tested extensively, and finally submitted ”as is.”
That represents a different approach to resolving the “topic submission” problem: Martin’s plugin would work for all Gerrit versions from v2.7.

The manifest plugin provides server-side utilities to operate on, and query information about repo manifests (XML) stored in git projects on the current server. This plugin provides APIs to update values in manifests, and to search for manifests with certain values.

The task plugin provides a mechanism to manage tasks which need to be performed on changes along with a way to expose and query this information. Tasks are organized hierarchically, and their definitions use Gerrit queries to define which changes each task applies to, and how to set the status criteria for each task. An important use case of the task plugin is to have a common place for CI systems to define which changes they will operate on, and when they will do so.

Gerrit CI Pipeline

Gerrit has finally a fully-feature CI Pipeline, thanks to GerritForge who invested time and resources to set up the https://gerrit-ci.gerritforge.com web-site.

During the Gerrit Hackathon 2015, Luca Milanesio, Doug Kelly and Khai Do have put together their ideas and skills to introduce an entirely automated and community-driven Jenkins set-up which allows to automatically generate the build jobs from the YAML files archived in the Gerrit-ci-scripts project.

The magic behind the system is that nobody directly controls the definition and execution of the jobs, but it is the collective contribution and code-review of the YAML files that automatically re-configure the Jenkins instance automatically.

Over 30K builds were executed last year, with an average of over 80 builds per day. Thanks to the Gerrit CI it is now possible to discover which plugins are available and stable on different branches of Gerrit and download the pre-built artifacts with a simple click.

What is still missing is an official “distribution site” of the Gerrit plugins; a place where successful plugin builds are installed on real Gerrit instances, tested and released. GerritForge is investing time and money to fill the gap and will provide a premium service called “Gerrit Central” available as an add-on to existing Enterprise Customers. The resulting fixes coming from this process of plugins validation will be contributed back to the community and will be accessible for everyone.

Gerrit Bazel build: a farewell to Buck

From v2.14 Gerrit is moving away from Buck and, after eight months of work of efforts for migrating the build system, David Ostrovsky has finally announced that the build is green and we are ready to move to Bazel, yeah.

Building Gerrit isn’t an easy task, with 35 repositories, 400K Java + 16K JavaScripts lines of code, over 140 dependencies and a complete JavaScript toolchain based on NodeJS. In addition to that, there are over 100 plugins automatically built with our CI system hosted and managed by GerritForge.

Gerrit started initially with Maven, but it was very slow and clumsy. After the London Hackathon in 2013 the project was successfully migrated to Buck, which promised to be much faster and flexible. However, this choice has driven the project build to a swamp of problems and bugs/fixes needed on top of Buck to make the build work.
As a result, a custom version of Buck needed to be built using Ant for potentially every branch of Gerrit development. The Gerrit project has submitted over 100 bugs to the Buck project over the three years of adoption.

Bazel is an OpenSource build tool based on an internal system used in Google and is much more advanced and stable, offering a simpler installation and an advanced sandboxing capability to isolate builds and results.
Differently from Buck, Bazel promises both speed and accuracy, qualities that were not always present at the same time.

During the Hackathon, David posted a milestone change named “Remove Buck build” which is currently under review. We all hope that the change will be merged very soon and give the final farewell to Buck build, and our thanks for having helped and supported us in our journey for over three years.

Gerrit reviews from e-mails

Patrick Hiesel from Google presented a very innovative feature that extends the ability to interact with Gerrit reviews by just answering to e-mails.

The feature is still in the very early stages of development  but the demo showed at the Summit was impressive. When you receive the e-mail notification from Gerrit with the comments of people to your code, you just answer in-line to the e-mail and … the magic happens! Gerrit fetches the e-mail automatically and understands the in-line replies as comments to be added to the reviews.

This new workflow dramatically reduces the cycle time of interactions during the review and represents IMHO the “killer feature” to push Gerrit to the top of the Code Review systems currently on the market.

Let me recap what you have to do currently with Gerrit:

1. Receive a notification e-mail
2. Read the comments
3. Click on the change link
4. Open a browser at the change page
5. Sign-in (assuming that you are using PolyGerrit, it would work on Mobile too)
6. Locate the comment you wanted to reply
7. Click on the comment
8. Click on Reply
9. Enter your Reply
10. Click save
11. Go back to the main change screen
12. Click on Reply
13. Click on Post

… and with the inbound e-mail ingestion in Gerrit it will be:

1. Receive a notification e-mail
2. Read the comments
3. Click on Reply
4. Insert your replies in-line
5. Send

There are issues, though, mostly related to security and trustworthiness of the e-mails as the vehicle for reviews.
We know that e-mails can be SPAMs or can be forged by faking source e-mail addresses. Currently, the prototype shown was only matching the e-mail sender to associate to the reviewer identity, which is fine for the majority of the cases but could raise some concerns regarding compliance.

The reviews coming from e-mails will be appearing with a different style and will be noticeable compared to more secure web-based comments. That would allow judging the comment accordingly and avoid over-reliance on their value.

It has been suggested as well to consider the integration of PGP-signed emails and the matching of the PGP-Key with the one stored in Gerrit for that user: that would be the perfect secure solution to avoid SPAMs or forged e-mails risks. However, Patrick did not commit to implementing the feature at this level for the initial MVP.

Inbound e-mail processing is a feature to keep under the radar as it will cause a wave of adoption of Gerrit because of the speed-up of entire Code Review lifecycle and consequently the time-to-market of the development of projects features.

Keep the conversation flowing with Gerrit at OpenStack

Khai Do, the maintainer of the Gerrit Review at OpenStack, has presented the challenges of managing comments with a large-scale project.

The OpenStack numbers for Code Review are astonishing:

  • Nine servers (1 master + 8 slaves)
  • 1500 repositories
  • 400K changes
  • 20K users
  • 700 events generated every hour

In addition to the scale of the installation, OpenStack allows third-party to connect to Gerrit using stream events and trigger validation builds. This workflow is code-named TCPI at OpenStack. There are currently 180 registered TCPI which generate *a lot* of messages appended to each change under review.

The overload of information associated with a change makes the “discussion flow” hard to follow in Gerrit: each change is swamped by CI messages which make the overall review unreadable.

Khai has developed a plugin that allows avoiding storing all those messages as regular reviews in Gerrit and collect them instead in a relational database. The overall result is then nicely rendered in a different section of the change, making the review discussion visible and flowing again.

The plugin works out of the box on the current version of Gerrit. Well done Khai.

Infinite Gerrit

Haithem Jarraya from GerritForge presented the idea of adopting a much more scalable storage for JGit based on Apache Cassandra. Shawn Pearce experimented the same scenario a few years ago and contributed an initial prototype on GitHub: piggybacking on the same concept, the new experiments are now driven by the need of scaling up Gerrit in space and number of nodes.

Gerrit Multi-Master is getting closer day-by-day, thanks to the joint efforts of all contributors from different points of view:

  • Sessions can be externalized to a flat-file to supports sharing across nodes (Qualcomm contribution)
  • Indexes and Caches can be aligned across nodes through events (Ericsson contribution)
  • ElasticSearch will be soon available as alternate shared indexing engine (Sony & CollabNet contributions)

Haithem now is adding one extra significant piece of the Jigsaw: the ability to have a scalable shared and extensible storage that allows all the master nodes of the cluster to read/write JGit Pack files at maximum speed. Additionally, thanks to Apache Cassandra multi-nodes data sharing and replication. You will be able to dynamically extend and reallocate the size and structure of the storage without impacting the current operations on the Gerrit Cluster.

The Cassandra backend wouldn’t cover the ref-database, which could be implemented with an entirely distributed implementation such as JGit Ketch (still in early development) or a more standard based on Apache Zookeeper.

Accounts and status of NoteDB

The task of migrating all the Code Review meta-data to the Git repository, aka NoteDB, started over two years ago. Edwin Kempin from Google, presented the current status of the implementation, with a focus on the Accounts migration.

In Gerrit v.2.13 there is already a new repository dedicated to the archiving of users, called All-Users. However, some of the information are still stored in Reviewdb, such as the external ids. Accounts will be exposed via REST-API and sensitive information encrypted end-to-end on the repository, using the same technique used for secure.config.

A new “magic ref” concept has been specifically forged for the All-Users use-case: the reference to their branches as refs/users/self. Each user will be able to get its meta-data by only fetching refs/users/self from the All-Users repository; easy isn’t it?

There is still one piece of information that will still stay outside NoteDB: the reviewed flag. The choice was made because of the inherent volatility of the information: NoteDB would have been overkill for a piece of information that lasts a few minutes or maximum hours typically. The default implementation will be H2 but it could be then replaced with something more “multi-master” aware.

What’s left? Gerrit Groups are the very last piece of the jigsaw and then NoteDB will be finally 100% feature complete. Bye bye DataBase, NoteDB is approaching fast!

Zero-Downtime Gerrit Upgrades

Luca Milanesio from GerritForge closed the Summit with a case-study on how GerritHub.io achieved a 100% zero-downtime migration process, with limited disruption to its 10K users.

Apart from Google, the current implementations of Gerrit Code Review around the world do not allow to keep the service running in case of upgrades between major releases. That was true until GerritHub.io recently introduced a well-testing roll-out mechanism inspired by the well known “blue-green” deployment.

The approach adopted by GitHub, in the case of DB upgrades, is to advise the customers up-front and schedule a planned outage of the system. Last time that this happened was last year and the blackout lasted for around an hour. However, GerritHub.io decided to be different and developed a strategy where the old version and the new version can work side-by-side by synchronizing Git repository and reviews, even across different versions of the DB schema and index.

The “preparation phase”, or Step-1 as Luca described it, may take even days or weeks to complete because relies on a low-bandwidth mirroring to avoid service disruption on the current user-base. Once the two instances are aligned, the subsequent steps will take only a few minutes.

During the “flipping” of the blue (old release) with the green (new release) instance, the users will notice that the repositories become read-only and receive a courtesy message saying “Upgrade is in progress, all projects are read-only. Please retry a few minutes later”.

The read-only “service degradation” would last only for a few minutes (2/5 minutes) and wouldn’t cause a service disruption for all the other users that are fetching, cloning or just browsing the reviews.

The Gerrit Hackathon

gerrithackathon-2016

Even though this year we had only two “hacking days,” the overall productivity has been remarkable: 158 changes created, with 82% of them merged during the Hackathon.

Bazel Build

Authors: David Ostrovsky, Luca Milanesio, Edwin Kempin, Han-Wen Nienhuys

Changes: https://gerrit-review.googlesource.com/#/q/project:gerrit+after:2016-11-10+before:2016-11-17+message:bazel

The summary of the changes is perfectly represented by David’s announcement to the Gerrit mailing list:

“I’m pleased to announce, that we are moving from Buck to Bazel build tool [1].
I’m working for a while on the transition now, and we are reaching the feature
parity for Bazel build toolchain.

I think that Bazel is a better tool for us and provides the following advantages:

* all actions are hermetic by design (no arbitrary python code execution)
* bootstrapping doesn’t require Ant
* can be installed on the main operating systems, including Windows
* better support for re-using of build rules across local and remote repositories
* switching to different branches wouldn’t mean rebuilding build tool
* extensible rules
* failed tests are not cached
* flaky tests are re-run multiple times
* error prone static analyzer integration out of the box

I would like to thank Shawn for supporting this project, and reviewers/contributors:
Han-Wen Nienhuys, David Pursehouse and Damien Martin-Guillerez from Bazel team.

Also big thanks to Luca and GerritForge for helping out with the CI and running a *lot* of tests.
Here is my related talk from Gerrit User Summit 2016: [2].

[1] https://bazel.build
[2] http://ostrovsky.org/gerrit/bazel-build-gerrit”

Allow plugins to define “has” search operands

Author: Martin Fick

Changes: https://gerrit-review.googlesource.com/#/c/91514/

Plugins can define new search operands to extend change searching.
Plugin methods implementing search operands (returning a
`Predicate<ChangeData>`), must be defined on a class implementing
one of the `ChangeQueryBuilder.ChangeOperandsFactory` interfaces
(.e.g., ChangeQueryBuilder.ChangeHasOperandFactory). The specific
`ChangeOperandFactory` class must also be bound to the `DynamicSet` from
a module’s `configure()` method in the plugin.

The new operand, when used in a search would appear as:
operatorName:operandName_pluginName

A sample `ChangeHasOperandFactory` class implementing, and registering, a
new `has:sample_pluginName` operand is shown below:

 @Singleton
 public class SampleHasOperand implements ChangeHasOperandFactory {
 public static class Module extends AbstractModule {
 @Override
 protected void configure() {
 bind(ChangeHasOperandFactory.class)
 .annotatedWith(Exports.named("sample")
 .to(SampleHasOperand.class);
 }
 }

@Override
 public Predicate<ChangeData> create(ChangeQueryBuilder builder)
 throws QueryParseException {
 return new HasSamplePredicate();
 }

Zoekt

Author: Han-Wen Nienhuys

Changes: https://gerrit-review.googlesource.com/#/q/before:2016-11-17+after:2016-11-10+project:zoekt

Han-Wen has officially announced at the Gerrit Hackathon, the general availability of the Zoekt code search engine.

“Hi there,

I’d like to announce “zoekt”, a search engine for source code I wrote over the last month or so. It was made to work well with (large) Git based repositories, so I think some of you may find it useful.

If you’re interested in code search, please try it out, and let me know about your experiences.

http://github.com/google/zoekt
http://gerrit.googlesource.com/zoekt

I didn’t do any work to try and integrate it with Gerrit/Gitiles, but
if someone wants to invest effort in making that happen, I’d be
happy to review CLs. “

ElasticSearch Index

Authors: Hugo Ares, Dariusz Łuksza

Changes: https://gerrit-review.googlesource.com/#/q/before:2016-11-17+after:2016-11-10+project:gerrit+message:elasticsearch

Small steps towards the goal of having ElasticSearch integrated as Gerrit secondary index:
– On-line reindexing (in-progress)
– Accounts indexing (in-progress)

Plugin examples

Author: Martin Fick

Changes: https://gerrit-review.googlesource.com/#/q/before:2016-11-17+after:2016-11-10+project:plugins/examples

Gerrit cookbook has become over the years a mix of different type of plugins functionality. That is good and bad at the same time. A typical “cookbook” should have a set of recipes for obtaining a final dish ready to eat … whilst our was more like a mixed salad with a bit of everything.

Martin started the noteworthy task of reorganizing the cookbook in a set of self-contained example, hopefully,  easier to manage and with a clearer understanding.

Cassandra Repository Manager

Author: Haithem Jarraya

Changes: https://gerrit-review.googlesource.com/#/q/before:2016-11-17+after:2016-11-10+project:libs/modules/repomanager/cassandra

Haithem started a new change (still in draft at the moment) for plugging an alternative JGit DFS implementation to the Gerrit repositories. It is the very first time that such a challenging goal is attempted outside Google data-centers and BigTable/GFS infrastructure. If we succeed in completing the implementation and demonstrating that the resulting architecture is more robust and scalable than the local file-system, it would be a first 100% OpenSource distributed JGit backend ever.

Gerrit LibModules

Author: Luca Milanesio

Changes: https://gerrit-review.googlesource.com/#/q/message:libModule+after:2016-11-10+project:gerrit

Luca discussed how to “plug” an external repository manager into Gerrit: it is something “similar” to a plugin but more fundamental to the system. Differently from a plugin, it needs to satisfy the following requirements:

  • Loaded at start-up time only
  • Cannot be unloaded
  • Must be injected in the primary Gerrit sys injector

It is not the first time that we need to introduce a “modular piece of software” which isn’t part of Gerrit Code Review:

  • Java CryptoProvider – BouncyCastle
  • Encrypted secure store for gerrit.config
  • Servlet filter for authentication and SSO
  • JDBC Interceptor for JavaMelody
  • Multi-hosted Git repository directories

Instead of creating “yet another exception” in Gerrit, we discussed amongst the hackathon members and agreed to come up with a new concept: LibModules.

The rationale behind the name is:

  • They need to be loaded from the same Gerrit class path from /lib
  • They provide extra Guice modules to be added to the sys injector at start-up

The configuration of a set of LibModules in Gerrit is straight-forward:

[gerrit]
installModule = com.mycompany.MyModule
installModule = com.googlesource.gerrit.modules.FancyModule

Now that the change is merged and the new concept has become part of Gerrit, we are expecting a growing number of LibModules to become available.

Removal of references to LocalDiskRepositoryManager

Authors: Hugo Ares, Shawn Pearce

Changes: https://gerrit-review.googlesource.com/#/q/before:2016-11-17+after:2016-10-11+project:gerrit+message:LocalDiskRepositoryManager

Shawn and Hugo started removing the explicit references in Gerrit to the local filesystem for resolving Git repositories. Those changes are needed to fully support an alternative implementation of a Repository Manager not based on a local filesystem anymore.

DynamicBeans for Gerrit Plugins

Author: Martin Fick

Changes: https://gerrit-review.googlesource.com/#/q/before:2016-11-17+after:2016-11-10+project:gerrit+message:DynamicBeans

Until now it has been possible to create new SSH commands or REST API through plugins, which is great but sometimes not enough. Martin came up with a use-case where they need to rather extend the current core commands, without having to necessarily change its code. How can you satisfy this use-case with plugins? Martin has the solution and is called “DynamicBeans”.

It is definitely an interesting use-case that is going to trigger a lot of interest and discussions amongst the Gerrit Community.

Analytics plugin

Author: Luca Milanesio

Changes: https://gerrit-review.googlesource.com/#/q/after:2016-11-10+project:plugins/analytics

One of the things that people are missing in Gerrit, when comparing it to GitHub, is the overall repository statistics:

  • List of contributors with number of commits / adds / remove
  • Project’s statistics of number of commits over time

The new analytics plugin extends the Gerrit project’s SSH and REST API to expose aggregated data extraction. It is extremely fast compared to GitHub because it works purely in streaming and doesn’t actually load the data in memory. The amount of data generated by the analytics can be huge and is intended to be used by an external analysis and dashboard system. Differently from the typical Gerrit’s API, the returned result has one item per line instead of a big unique JSON object. The rationale is that to generate and process a set of JSON elements in streaming, you need to make each record self-contained and processed independently. That would allow as well batch-processing with a parallel system, without having to parse the entire file content all at once.

Example of how to extract the list of contributors out of a Gerrit project via SSH:

$ ssh -p 29418 admin@gerrit.mycompany.com analytics contributors

{"name":"John Doe","email":"john.doe@mycompany.com","num_commits":1,"commits":[{"sha1":"6a1f73738071e299f600017d99f7252d41b96b4b","date":"Apr 28, 2011 5:13:14 AM","merge":false}]}
{"name":"Matt Smith","email":"matt.smith@mycompany.com","num_commits":1,"commits":[{"sha1":"54527e7e3086758a23e3b069f183db6415aca304","date":"Sep 8, 2015 3:11:23 AM","merge":true}]}

Wrap-up and Summit in 2017

It has been a very intense and revolutionary Gerrit User Summit & Hackathon this year, with a lot of new faces, new contributors and new features coming in the next forthcoming releases.

At the summit, Shawn Pearce and Luca Milanesio announced the proposal to organize the event in Europe for next year, possibly in June/July or Oct/Nov 2017. The reason for changing the location is to attract the feedback from more Gerrit Users that have not been heard so far and increase the participation of the community in the future of the of Project.

The summit has been already endorsed by the major organizations driving the Gerrit Code Review Project and other very active sponsors of the OpenSource Community, including CloudBees, CollabNet, eSynergy, Google, GerritForge, SAP and SkillsMatter which has offered to host the event at CodeNode.

Shawn Pearce, the Gerrit Code Review project founder, will send in the next few weeks a Survey to capture the opinion of this proposal from the Gerrit Community.

See you in 2017 for new and amazing features coming on Gerrit Code Review.

Luca Milanesio – GerritForge.

 

 

 

 

 

 

Gerrit User Summit 2016: Ten days to go

gerritforge-keepcalmandcodereview-copy

In ten days time, the 2016 Gerrit User Summit will open its doors at the Googleplex Campus in Mountain View – CA.

It is going to be an amazing event, with a lot of exciting updates from the Gerrit Community, thanks to the number of innovations that are coming into the platform, from large files support (Git LFS), HTML5 Polymer-based new UX, NoteDB, multi-master updates and a lot more.

GerritForge will be present with five attendees and six amazing talks, covering many of the aspects of the world of Code Review and Continuous Delivery Pipeline:
Code Review Analytics
High Availability and Zero-Downtime upgrades
Infinite scalability with Gerrit on Apache Cassandra
Jenkins 2.0 Continuous Delivery pipeline for Gerrit
Speeding up builds with Bazel on Gerrit
Robot feedback management for Gerrit

Once again, as we always did in the past, we continue to fuel new ideas and innovation to the world of Code Review, with the feedback from the Gerrit User’s Community and developing the ideas as OpenSource, always.

See you soon at the Gerrit User Summit 2016.

Gerrit Summit 2016 is coming

google

Four weeks from now, the eighth edition of the Gerrit User Summit will open its door at Google HQ in Mountain View – CA, 12th-13th of November 2016.
It has been a long journey since the first GitTogether in 2008, and after the split between the Git[Hub Universe] summit and the traditional “unconference” style Gerrit event at Google’s, things have changed quite a lot. While Gerrit remained a 100% OpenSource user-centric project, GitHub has attracted $350M in VC, and they have been losing traction over the years to join the unconference-style events.

What’s new this year?

For the first time, the proposals of talks to the Gerrit User Summit are submitted in Gerrit directly (yeah!) on the summit/2016 repository.

The list of currently approved talks is available by searching for “status:merged project:summit/2016” (https://gerrit-review.googlesource.com/#/q/status:merged+project:summit/2016)
The talks awaiting review are under “status:open project:summit2016” (https://gerrit-review.googlesource.com/#/q/status:open+project:summit/2016)

How cool is that? I foresee already a Doodle plugin for Gerrit 😉

How to register for the User Summit?

Shawn Pearce has prepared a Registration Form for you to sign-up to the event:
https://goo.gl/forms/oeEnQweHl2noNSnn1

Once you access the Registration Form at the above URL, you need to sign-in with your Google Account credentials and then complete the following information:
– Your name
– Your Organisation
– Your previous attendance to the user summit
– Any dietary restrictions

The User Summit is FREE for EVERYONE, including novice users of Git and Gerrit Code Review, but you would need to register beforehand.
The Summit is a unique opportunity to learn about Gerrit new feature, contribute to the product roadmap with your needs and requirements and, most of all, network with other users to learn new use-cases where Gerrit can be very helpful.

How to submit my talk proposal?

Well, you need to demonstrate a good understanding and use of Gerrit Code Review if you want to teach and talk to other people about it! At the end of the day, if you want to talk about Gerrit you should be able to clone a repository and submit a patch to a project 🙂

If you need just a little help … see my “Diffy super super talk” example:

$ git clone https://gerrit.googlesource.com/summit/2016 && (cd 2016 && curl -Lo `git rev-parse --git-dir`/hooks/commit-msg https://gerrit-review.googlesource.com/tools/hooks/commit-msg ; chmod +x `git rev-parse --git-dir`/hooks/commit-msg)
$ cd 2016
$ cat - > sessions/my-amazing-talk.md
# My amazing talk at Gerrit User Summit

Hi folks, this is my super-duper-talk. You should be interested in it as I will unleash the dark force of Code Review Diffy Kung Fu Review Cuckoo.

*Diffy, Birds & CO. Inc.*
^D
$ git add sessions/my-amazing-talk.md && git commit -m "Diffy super-duper talk"
$ git push origin HEAD:refs/for/master

Talks highlights.

There are already some fascinating talks submitted and approved and more will undoubtedly come in the next couple of weeks. We will start sharing some highlights of what’s happening at the conference. Here is the overview of the first talks.

What’s new in Gerrit 2.12 and 2.13

Two major versions of Gerrit have been released since the last summit in 2015, and they contain significant improvements to the platform:

  • Topic submission workflow – aka Git commits across repositories  (v2.12).
    Group multiple changes in a “topic” and having them merged as a whole, even across multiple repositories, in a single submit operation.
  • GPG signed pushed verification (v2.12).
    Allows people to upload their GPG public keys into Gerrit and have them used to verify Git signed commits.
  • Large File Storage support (Git LFS) (v2.13).
    Gerrit finally supports the automatic management of large files outside the Git repository. The feature is fully pluggable and exposed via plugins. Amazon S3 and Local file system support are available at the moment, but more plugins are here to come on this feature.
  • Gerrit metrics (v2.13).
    Expose the internal metrics to external consumers. The feature is exposed for plugins to gather this data and send to external systems for analysis and visualization purposes. Graphite, ElasticSearch, and JMX plugins are available.
  • Hooks plugin (v2.13).
    Finally, the Gerrit hooks mechanism have been entirely externalized and implemented in a pluggable way. The legacy hooks have become a core plugin. However, you can now leverage the new extension to develop a new-generation of hooks by leveraging the new extension points provided.
  • New HTML5 UX with WebComponents – PolyGerrit preview (v2.13).
    The next generation of Gerrit UX based on Polymer Web components is available. Even though not complete, offers a sneak preview of what the new interface looks like and, if you like it as-is and is good enough for your use-cases, you can enable and start using it already. Both GWT and Polymer-based UX are using the same REST API, and thus the changes generated and reviewed with them are 100% interoperable.

There is more to come.

In the next few days we will keep on publishing the highlights of the topics coming at the Gerrit User Summit this year, stay tuned and REGISTER NOW at:
https://goo.gl/forms/oeEnQweHl2noNSnn1

The GerritForge Team.

GerritForge helps Gerrit 3.0 stability

Gerrit 3.0 plan announced: we need stabilisation now

Screen Shot 2015-11-23 at 09.52.19

Gerrit 3.0 plan and its NoteDB reviews have been officially announced at the Gerrit User Summit 2015. It is already available as an experimental feature in the current Gerrit master but it needs much more stability in order to be officially supported for production.
GerritForge decided to help and reuse its existing continuous integration system to validate every Gerrit patch set against the current and the new NoteDB review persistence back-end in order to avoid regressions during the 2.13 and 3.0 development

Pre-commit validation by GerritForge CI

If you have posted a patch to gerrit-review.googlesource.com in November, you may have hopefully received a Verified+1 from a strange user with a Diffy logo on the side.
GerritForge’s provided CI on gerrit-ci.gerritforge.com fetches automatically every patch-set pushed to gerrit-review.googlesource.com and triggers a slightly modified Gerrit build with the purpose of checking whether the code change introduces a regression or not. This may seem at first sight a quite normal Gerrit to Jenkins job integration, however implementing it on top of Google’s multi-master replicated installation was not a piece of cake.

Gerrit Trigger plugin limitations on multi-master setups

Jenkins has already an out-of-the-box integration with Gerrit provided by the Gerrit Trigger plugin maintained by Robert Sandell – Cloudbees. It leverages the Gerrit stream events through an SSH channel and make use of Gerrit REST API to action them according to the build result.
The Google’s Gerrit setup, however, is not a trivial one-node installation and is further limited by the security constraints of the Google infrastructure, which does not allow any incoming SSH connectivity.
Additionally all concept of “getting the events in a stream” isn’t going to work when events can come concurrently from multiple places at the same time: who is going to define the “global ordering” and how to put all those events in a single TCP/IP Socket? Even UDP would not work in this case because SSH channel requires confidentiality between two and only two peers.

Alternatives to SSH

During the hackathon, other approaches have been discussed by Shawn Pearce, including the use of HTTP WebSockets (or Cometd) for fetching events without the need of an SSH connection. Events are still distributed and generated by multiple masters all the time, and the Jenkins plugin would then have the onus of contacting all the Gerrit servers and keep a connection opened to all of them. This is clearly not going to work because the number of servers, their IPs and locations may change at any time and the solution would eventually be in danger of losing precious events.

Back to polling

The only solution we envisaged was to fall back to a polling logic where Jenkins ever 10 minutes is asking Gerrit “what’s new since last time we spoke?”. This solution goes against the main reason the Gerrit Trigger plugin was designed: avoiding SCM polling. It is, however, a much better and optimised polling strategy and let’s see why.

Query and then fetch

The typical Git SCM polling relies on fetching all references every poll interval and detect if new Git commits are available. This is notably slow and generates a huge overhead on the Git server. The approach we took is quite different and makes use of the Gerrit search capabilities that are way faster and more powerful than a simple Git fetch.
Jenkins first ask Gerrit the list of changes and associated commit-IDs involved in any event since the last polling time: the result may include patchsets that have been already built to avoid having any gaps between polling intervals. The search is fast and implemented in … you know, Google is a search company isn’t it?
Once the list of candidate commit-ids is identified, Jenkins goes through all of them and checks using the Gerrit REST-API:
– has it been build during my previous execution?
– has it been already accepted (or rejected) by me?
The Commit-IDs that results as not being checked before and not yet validated are then used to trigger a specific job parametrised on:
– Specific branch
– Specific change ref-spect
Fetching is performed avoiding any wildcard and the corresponding load on the Git server is minimum. Fetch (Git protocol) + build (using Buck) + test (unit + integration) + review feedback (REST API) is taking an average of 5 minutes, which is an amazing result if you consider the size of the Gerrit project and the typical slow speed of a default Jenkins Git fetch.

The bottom line

Using the query + fetch approach, which seemed a bit slow and old-fashioned at the beginning, was eventually very simple and successful. Instead of setting up SSH hostkey verification, key exchange and ad-hoc channels, the only configuration needed is a valid Gerrit user and the HTTPS endpoint URL, the same used for cloning the code.
The solution is much more reliable as SSH channels are notably unstable and consume server threads. The only drawback is the slight delay between the patch-set upload the start of the build (at max 10 minutes) which is acceptable in most cases.
Results
Since its roll-out more than 1200 patches have been checked and rated, a lot of potentially Gerrit regression avoided and more importantly we have prevented the NoteDB code to start diverging regarding stability from the current mainstream development.

How can re-trigger validation for a single change?

We have enabled anyone to trigger ad-hoc executions of the Gerrit validation flow using the following URL:
https://gerrit-ci.gerritforge.com/job/Gerrit-verifier-flow/build
This is a standard Jenkins parametrized build that request the change-id to be built, as either SHA1 or number. Once the job is triggered the build will be executed and the validation feedback applied to your change, regardless of the previous build or validation status.

Pingdom status for GerritHub.io

Image

Screen Shot 2014-09-07 at 23.39.01You can check the status of GerritHub.io services in real-time thanks to the public page offered by PingDom.com

The GerritHub.io status page is http://status.gerrithub.io and displays:

  • Current status with response time
  • History of the past 7 days with uptime
  • Details of the last 24 hours

Tonight for instance reports a temporary service outage (3 times, around 15′ each) caused by an intermittent unavailability of the GitHub API. As GitHub was not able to provide the validity of its OAuth code credentials, GerritHub was not able to allow the completion of its login handshake and thus resulting in a partial outage.

We will use the PingDom.com reports to reinforce our production infrastructure and make GerritHub.io more resilient in the future. For instance in this case (GitHub API unavailable) we will look at reusing cached credentials for allowing known people with non-expired Gerrit cookies to complete their operations. For unknown users, we will display next time a courtesy message explaining that the sign-up is unavailable for GitHub API temporary outage, avoiding the allocations and time-outs of HTTP connections.

 

 

GitMinutes #30: Luca Milanesio on Gerrit Code Review

git-minutesMany thanks to Thomas Ferris Nicolaisen for inviting me to talk about Gerrit Code Review at GitMinutes.

It has been a very interesting discussion on the benefits of Code Review and how Gerrit can help out small and large companies embracing it.

The interview is available on-line at http://episodes.gitminutes.com/2014/07/gitminutes-30-luca-milanesio-on-gerrit.html, alternatively you can download and listen the 1h 27′ conversation on PodCast at https://itunes.apple.com/de/podcast/gitminutes-podcasts/id637843725?l=en.

Use the force Luca!

We started (of course!) talking about the [in]famous force push of 186 Jenkins repositories to GitHub, I was on the Top-10 HackersNews over 7h … so I was expecting the question to pop-up during the interview 🙂

My friend Alex Blewitt took the opportunity as well to forge a Star-Wars like headline for his InfoQ article on what happened.

Git adoption in the Enterprise, where all began

We moved the discussion to the foundation of my business on Git and Code Review and the reasons and challenges that an Enterprise company is facing when moving to Git. We went through the history on how LMIT started GitEnterprise.com and then focused on Gerrit Code Review based product and services for large Enterprises World-Wide: a niche and successful business nowadays.

GitHub or Gerrit? or both with GerritHub?

As I expected, we ended up comparing GitHub and Gerrit analysing the similarities and differences between the two. This topic has been presented as well in two conferences at Gerrit User Summit @GooglePlex – Mountain View CA and 33rd Degree.org Java Developers Conference in Krakow; slides are available at http://www.slideshare.net/lucamilanesio/gerrit-codereviewgit-hubplugin.

Gerrit has historically been considered as “more difficult” than GitHub: true in the past but not anymore today apart from the Web User-Experience CSS styling, much nicer and pleasent on GitHub. The availability of http://gerrithub.io allowed over 1,800 developers since October 2013 to get started with Gerrit in less than 5 minutes by watching an Gerrit Introductionary YouTube video: using it was then just 3 clicks away, no installation or configuration needed! The availability of an easy and accessible Public Cloud instance represents a big improvement in accessibility and usability of Gerrit.

For which teams is Gerrit the right choice?

We talked about the “typical learning curve” of people coming from previous version control systems, such as Subversion. Does it make sense to get started with Git and Gerrit at the same time? When is Gerrit needed and when is it going to provide most of its value?

I’ve covered the topic in the past webinars and talks: hands-on Webinars recordings are freely available on-line at:

The size of the project (in terms of number of people x number of repositories) is typically one of the key factors in Code Review adoption. Gerrit however can be used as well as a standalone OpenSource Git Server , even without leveraging its Code Review capabilities: this makes the choice of Gerrit a good first step towards a smoother Git adoption.

What are Gerrit Topics about?

We went through a very interesting discussion about “Gerrit Topic”, a feature that is not new to Gerrit but is sometimes forgotten besides its important and relevance for medium-large teams.

With the forthcoming support of multi-repositories atomic commits in Gerrit, it will be possible to merge multiple changes on multiple repositories at the same time for a single topic. This feature is not ready yet but coming hopefully in the near future and Google Gerrit Team developers and contributors are working on it.

The ability to make an atomic commit across multiple repositories will allow to have a more consistent Jenkins build process as well, with less broken builds because of interdependent changes on multiple components.

Who is using Gerrit today?

We talked about the adoption of Gerrit in the community, which is growing year after year. A lot of medium companies adopted Gerrit in the past, including Spotify side-by-side with GitHub.

The ability to “submit a change” to any project without the risk to break the build is definitely an incentive to encourage even more people to contribute to share the knowledge and improve the code base, without the risk of breaking anything or  forking the code. This is one of the reason that drove large OpenSource organisations such as the Eclipse Foundation and OpenStack to the adoption Gerrit Code Review in their tools platform.

How to embrace Code Review in a Team or Company?

We went through an interesting comparison / discussion of Agile Methodology vs. Code Review. Often Teams misunderstand and confuse the concept of “review” with “pair-programming”: the problem was well analysed in my book “Learning Gerrit Code Review” (available on Amazon.com at http://www.amazon.com/Learning-Gerrit-Code-Review-Milanesio/dp/1783289473). I defined the pair-programming as a dot in a time/people space: two developers writing a piece of code at the same time. This however does not exclude all the other points in the time/people space where multiple people at different times will read the code and provide their feedback: pair-programming is then a “specific example” of the “code review space”.

Because of the different perspectives (pair-programming is a dot whilst code-review is a “cloud of dots” in time/people space) they are not one exclusive of the other: they are equally important and both enable effective collective code ownership and knowledge sharing.

References and greetings.

It has been a very long but interesting discussion with Thomas and hope you’ll enjoy it.

See below the links of the resources we mentioned during the interview:

Thanks again to Thomas for his fantastic initiative: GitMinutes PodCast!

Luca Milanesio 

Heartbleed: GitEnterprise and GerritHub are safe

heartbleedA few days ago a large part of the Word Wide Web has been found vulnerable to the heartbleed bug in OpenSSL.

What is the vulnerability about?

The vulnerability is effectively a bug in all the versions of OpenSSL from Ver. 1.0.1 to 1.0.2. In reality a lot of web-sites are either using the older and still popular OpenSSL 0.9.8 or they have already upgraded to the latest patched version of OpenSSL and thus are NOT vulnerable to heartbleed.

 

Are you passwords safe ?

In a nutshell yes when they are posted or exchanged with a server that is not vulnerable to this attach:

  • GitEnterprise (gitent-scm.com) has never used any OpenSSL 1.0.1-1.0.2 (see: https://www.ssllabs.com/ssltest/analyze.html?d=gitent%2dscm.com) and thus is not vulnerable: you can keep your existing password as they are safe.
  • GerritHub (gerrithub.io) has been vulnerable for only 5 days and then has been upgraded (see https://www.ssllabs.com/ssltest/analyze.html?d=gerrithub.io). However GerritHub DOES NOT exchange passwords over the Internet but rely on your existing GitHub session through OAuth Token authentication. This means that during the 5 days of vulnerability your account has NOT been at risk on GerritHub.

What about GitHub ?

Unfortunately GitHub has been vulnerable (see https://github.com/blog/1818-security-heartbleed-vulnerability) but the problem has been resolved or is under resolution right now as the nodes get upgraded.

We do recommend then to change your GitHub password in order to be sure that any previous credentials potentially stolen would not impact the security of your account and repositories.

GerritHub relies on GitHub OAuth, so is GerritHub at risk as well ?

In real terms the answer is “potentially yes”: if a potential attacker had been stolen your GitHub password, he could have initiated a login on your behalf and then accessed GerritHub as well.

How can I strengthen my GitHub  security ?

GitHub already support today the two-factor authentication (see https://help.github.com/articles/about-two-factor-authentication): if you have this extra security enabled, nobody other than you can ever access your account, even if they could have potentially stolen your password.

Can I have a GerritHub account secured independetly from GitHub ?

Not yet, however we are working on an advanced security option for the private GerritHub accounts. We will offer for a monthly extra fee:

  • Access to your GitHub private Teams and Repositories
  • Extra scripting functionality to hook Gerrit events on the server side
    (commit validation, issue tracking association, …)
  • Integration with Atlassian Jira or BugZilla
  • Integration with BuildHive from CloudBees for Continuous Integration
  • Extra enterprise account protection for GerritHub.io accounts (additional password / X.509 Certificates)

Wow, that is amazing ! When can I get GerritHub private edition ?

We are currently in public beta stage, you can start using the implemented features for FREE during the trial by logging in to GerritHub using the URL:

https://review.gerrithub.io/login?scope=scopesPrivate

Can I provide suggestions and give feedback during the public beta trial ?

Yes, you are very welcome to provide your feedback and we are very opened to adjust the development of GerritHub private features to your needs !

For problems and getting support:
http://gerritforge.com/support

For suggestions and feedback, please use the Gerrit Code Review forum:
https://groups.google.com/forum/#!forum/repo-discuss

Is GerritHub OpenSource ?

Absolutely YES: GerritHub is based on Gerrit Code Review 2.10-SNAPSHOT master with a selected set of enterprise plugins:

  • GitHub plugin
  • Codenvy plugin
  • ITS-Jira plugin
  • Scripting provider plugin
  • SingleUserGroup plugin
  • Download commands plugin
  • Replication plugin
  • Gravatar plugin
  • Review notes plugin

If you want to directly review and contribute to Gerrit, you are welcome to the developers and contributors community !

 

 

-2 days to the Gerrit User Summit 2014

The Gerrit User Summit 2014 is about to start in only 2 days: it is going to be a two days of exciting news and innovations on the world of Code Review. There are names from the largest industries in the world that have adopted the Code Review workflow in large enterprise environments: Google, SAP, SonyMobile, Ericsson, IBM, Garmin, HP, CollabNet, GerritForge, Codenvy, Eclipse Foundation and LibreOffice.

During all this week there is a special promotional discount on the Learning Gerrit Code Review book. Additionally, for the attendees of the conference, there will be a limited number of signed paperback copies available at the session “Gerrit or GitHub? Take both !”

Learning-Gerrit-Code-Review-QRCodeIn order to redeem the book promotion, scan the QR code and enter one of the following PROMO-CODEs:

Book PROMO-CODE: LGCRB20
eBook PROMO-CODE: LGCReB20

 

 

The Gerrit User Summit Agenda has been published yesterday and has a lot of very interesting talks and announcements:

Day 1 – Friday 21st of March

  • What’s new in Gerrit 2.8 (David Pursehouse – Gerrit maintainer – SonyMobile)
  • Scaling Gerrit at Ericsson (Patrick Renaud, Vladimir Cantiru, Hugo Ares – Ericsson)
  • Monitoring Gerrit (Doug Kelly – Garmin)
  • Browsing Repository Content with Gerrit’s REST API (Simon Kaegi – IBM)
  • Gerrit@LibreOffice (David Ostrovsky – LibreOffice)
  • Gerrit plugins made easy with Scripting (Luca Milanesio – GerritForge)
  • The Angular revolution in Gerrit! (Dariusz Luksza – CollabNet)

The day 1 would end with a very interesting Q&A with the Gerrit User Community about the features they would like to see coming up in the next forthcoming releases!

Day 2 – Saturday 22nd of March

  • 2014 Roadmap (Shawn Pearce – Gerrit project founder, Google)
  • Gerrit@SAP (Edwin Kempin – Gerrit Code Review maintainer – SAP)
  • Integrating CLA and Origin checks with Gerrit (Denis Roy – Eclipse Foundation)
  • Guiding Diffy to the Enterprise land (Dariusz Luksza, Eryk Szymanski – CollabNet)
  • Collaboration at Scale: The Openstack CI toolbox (Khai Do – HP)
  • Gerrit or GitHub? Take Both! (Luca Milanesio – GerritForge)
  • Diffy gets Enterprise grade (Dariusz Luksza, Eryk Szymanski – CollabNet)
  • Continuous Development with Gerrit (Tyler Jewell & Luca Milanesio – Codenvy & GerritForge)

The day 2 will end with a meet-up with food and drinks sponsored and organised by Codenvy where the Gerrit Community can discuss and exchange their post-Summit impressions and ideas on the future of Code Review.

It is going to be again a huge leap forward for the Code Review community and the Git and Gerrit projects improvement !