Re: [orion-dev] preferred path to contribute patches

[Matthias Sohn <matthias.sohn@xxxxxxxxx>]

On Thu, Apr 11, 2013 at 5:15 PM, Matthias Sohn <matthias.sohn@xxxxxxxxx> wrote:

On Thu, Apr 11, 2013 at 4:33 PM, Mike Milinkovich <mike.milinkovich@xxxxxxxxxxx> wrote:

Simon,

 

Are you looking for something more than:

http://wiki.eclipse.org/Development_Resources/Handling_Git_Contributions#Gerrit ?

 

Lots of Eclipse projects are already doing this. I’m surprised Orion’s not already.

A Gerrit-based contribution workflow would be great. Do you have any pointers?

I can assist teaching the project how to do that, we use Gerrit for JGit/EGit development since 2010,

host it for SAP developers internally and I also helped Denis to setup the foundation's Gerrit server ;-)

The main entry point for learning about how to use Gerrit at Eclipse is here

http://wiki.eclipse.org/Gerrit

Basically you need to create a ticket for webmaster with +1 from project owner (should be easy for you :-)

then Denis will symlink the repository into Gerrit's repository tree and the project can start using Gerrit.

We do all changes using Gerrit Code Review and also do code review for all changes there. In order

to start using that it might make sense to still allow direct push for committers so that they can

shortcut code review until everybody is familiar with the Gerrit workflow. Though I would recommend

to do these direct pushes over Gerrit. This means the git URL to push changes would be different

from the one used so far. Switching on/off direct push for committers is a simple permission

configuration change in Gerrit.

The effect of enabling Gerrit for contributors is that they can simply push their contributions 

to the code review queue for the project's git repository instead of following a clunky process over

Bugzilla. In order to do that they use a different, magic refspec (HEAD:refs/for/master) to push 

which signals to Gerrit that they want to push the change for code review.

All changes pushed using that refspec will end up in Gerrit's review queue for the master branch 

(if you want code review for a different server side branch simply replace master with the respective

branch name). Contributors don't get the permission to push directly. Committers have the choice

either to also use Code Review or to push directly to the respective branch shortcutting code review.

As mentioned above the direct push for committers can be prohibited if the project wants to do

code review for all changes.

Reviewers can look at the change in Gerrit's web Ui and comment (inline in the source code

displayed in the web UI) and finally vote on each change. They can also download the change

in review and test it locally.

Usually changes in review get comments how to improve them, the author can then provide

a new version of the change (called patchset in Gerrit) which replaces the previous one.

This way the change can go through iterations without affecting the master branch

until everybody is happy with the last patchset which then can be submitted to the master

branch.

More information about the code review process itself is linked here

http://wiki.eclipse.org/Gerrit#Doing_Code_Reviews_with_Gerrit

Another very cool feature is Hudson based verification of all changes pushed for code review

before they reach the target branch. I.e. when a change is pushed for review and a corresponding

build job is set up, Hudson will start a build including the automated tests and also vote on the

change. This way broken code or tests will be automatically rejected by Hudson.

See http://wiki.eclipse.org/Gerrit#Verifying_Changes_on_Hudson_using_Gerrit_Trigger_Plugin

I'd like to again propose to enable the Orion Git repositories for Gerrit so that we

can use it for code reviews.

Any thoughts or concerns ?

--

Matthias