[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [orion-dev] preferred path to contribute patches
|
Hi Matthias, we actually discussed Gerrit
adoption again in a recent Orion meeting and decided to go ahead and enable
it. It was my "todo" to enter a webmaster request which I have
just done:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=416442
We still need to work through the Orion
Git UI workflows and document what a Gerrit workflow would look like for
committers and contributors. Orion doesn't currently have built in Gerrit
support so it won't be quite as smooth as it is in EGit.
John
From:
Matthias Sohn <matthias.sohn@xxxxxxxxx>
To:
Mike Milinkovich <mike.milinkovich@xxxxxxxxxxx>,
Orion developer discussions <orion-dev@xxxxxxxxxxx>,
Date:
09/02/2013 06:13 PM
Subject:
Re: [orion-dev]
preferred path to contribute patches
Sent by:
orion-dev-bounces@xxxxxxxxxxx
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 _______________________________________________
orion-dev mailing list
orion-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orion-dev