We have a similar process in place now with Bamboo... we merge pull
requests into the "pull-requests" branch in git, then Bamboo
automatically builds off of this branch. If the build passes, then we
can review the pull request using github's UI (instead of Gerrit) and
merge it into master.
It's basically identical except that I think that our merge into the
pull-requests branch is manual at this point so that we can eyeball the
incoming patchs first and see if they seem interesting at all before
they tie up a Bamboo build system.
It is cool that you can roll your own review system with Gerrit instead
of relying on github. It would be interesting to compare their comment
and review UIs to see how they compare to one another.
Seth Leger
The OpenNMS Group
On 8/27/13 10:19 PM, Carl Nygard wrote:
> Regarding the "test the merge before you commit", you should take a look at
> Gerrit as a front-end to your canonical Git repo. I've been using it for a
> few months, and there are three features it brings to the table that I've
> grown to rely on heavily:
>
> - Patch submission doesn't go directly to the repo. The patch sits in a
> kind of "purgatory" until someone reviews the code and accepts it.
> Acceptance is two-fold, a) does it build and pass tests, and b) is it a
> smart thing to do.
> - The (a) can be done automatically via a hook to Jenkins, so any patch
> submissions can be built and unit tests run automatically via Jenkins, with
> the results automatically passed back to Gerrit
> - The (b) is a subjective application of human intelligence, and Gerrit
> provides structure for making comments inline to the code. To this end,
> Gerrit also keeps track of "patch attempts" and as people modify their
> submission in response to comments, you can not only see the diffs from
> master, but also the diffs between patch revs.
>
> Gerrit can manage submissions against master or any other branch you have
> defined in Gerrit. It can also handle rebasing patches inside the tool when
> the rebase is clean (with a complete test/review cycle), which is handy
> when you have multiple submissions pending.
>
> If you have any questions about the process, I'd be happy to help. Be
> aware that Gerrit/Jenkins have been moving quickly and the existing web
> docs showing how to integrate the two are a bit out of whack with current
> state. I'd be happy to share our current configs if you want to try it out.
>
> --carl
>
>
> On Tue, Aug 27, 2013 at 7:42 PM, Seth Leger <s...@opennms.org> wrote:
>
>> Yeah, if we did the changes little-by-little it would make merging
>> easier. I know I sounded a little crotchety in my earlier message but I
>> definitely want to see a lot of this lint stuff cleaned up as well. I
>> think that having a nice, clean, well-documented codebase is a definite
>> plus when advertising OpenNMS to the world of potential users and
>> developers. And if you keep up your best practices in implementation
>> code, it makes it easier and less error-prone to layer abstractions
>> (like OSGi, ORM, etc) on top of the code.
>>
>> It would be nice to have a way to call a "heads up" to the developers
>> out there so that we could alert everyone that big changes are coming to
>> the code if we did want to do some lint cleanup en masse. The last
>> change like this was the slf4j logging update from DevJam 2013 and a
>> heads-up wasn't really needed since most of the developers were in the
>> same room. :)
>>
>> Some ideas that might make this process smoother:
>>
>> - A way to say "heads up! new code incoming!" to developers with
>> outstanding branches
>> - A script that could test merges to active branches and alert you if
>> the conflicts are high before you push (so you know beforehand how much
>> pain you are inflicting on others)
>> - Making it easier to Sonar your new code so that new code is always
>> lint-free
>>
>> In the meantime, I'm a big fan of de-linting any files that you happen
>> to be editing. If you are fixing a bug in a class, go ahead and clean up
>> the modifiers and javadoc! You're going to be running the code anyway to
>> test the bugfix so you might as well do some spring cleaning at the same
>> time.
>>
>> -- Seth
>>
>>
>>
>> On 8/26/13 11:44 PM, Ronald Roskens wrote:
>>> Yeah, I understand that point. As I've been playing around with a
>> development branch thats had a lot of forward churn, I find it difficult to
>> to merge from master.
>>> I can see that it will be easier to de-activate these high count rules
>> and work through the lower count issues and then progressively enable some
>> of these other rules. Since git lets you run hooks on commits, maybe the
>> thing to do there would be to add those hooks to a developer git repo so
>> these things could be implemented over time.
>>> I could create a repo with some of these scripts that re-format files so
>> that people could run them on their own dev branches.
>>> The stylistic stuff aside, I see it as a good learning tool to help
>> understand java programming better. I think what makes the most sense is
>> treat this like a GSOC project and submit pull requests that could be
>> vetted before they are merged to master.
>>> Ron
>>>
>>> On Aug 26, 2013, at 9:49 AM, Seth Leger <s...@opennms.org> wrote:
>>>
>>>> I'm concerned about making scripted changes like this en masse. A lot of
>>>> these lint cleanups are unnecessary and produce the potential for major
>>>> conflicts for people who are merging feature branches into master. The
>>>> benefit of removing a bunch of trailing whitespace in 30,000 lines of
>>>> code is minimal but the headaches that such a change could make when
>>>> merging branches are large.
>>>>
>>>> The trailing whitespace rule should be marked "ignore" in Sonar.
>>>>
>>>> The "final" param fixes and such should probably only be done inside a
>>>> module where you are currently working or are absolutely sure nobody has
>>>> outstanding branches. As we modularize things for OpenNMS 2.0, it's
>>>> going to be virtually impossible to guarantee that you're not cleaning
>>>> up code that somebody out there is working on to OSGi-ify it. The fewer
>>>> merge headaches during this transition the better so I would recommend
>>>> pushing your work off until after that.
>>>>
>>>> Mass scripted Javadoc fixes are probably OK since there are veeeeeery
>>>> few hand-edited Javadoc changes that go into existing code. Go wild on
>>>> those changes.
>>>>
>>>> -- Seth
>>>>
>>>>
>> ------------------------------------------------------------------------------
>>>> Introducing Performance Central, a new site from SourceForge and
>>>> AppDynamics. Performance Central is your source for news, insights,
>>>> analysis and resources for efficient Application Performance Management.
>>>> Visit us today!
>>>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
>>>> _______________________________________________
>>>> Please read the OpenNMS Mailing List FAQ:
>>>> http://www.opennms.org/index.php/Mailing_List_FAQ
>>>>
>>>> opennms-devel mailing list
>>>>
>>>> To *unsubscribe* or change your subscription options, see the bottom of
>> this page:
>>>> https://lists.sourceforge.net/lists/listinfo/opennms-devel
>>>
>> ------------------------------------------------------------------------------
>>> Introducing Performance Central, a new site from SourceForge and
>>> AppDynamics. Performance Central is your source for news, insights,
>>> analysis and resources for efficient Application Performance Management.
>>> Visit us today!
>>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Please read the OpenNMS Mailing List FAQ:
>>> http://www.opennms.org/index.php/Mailing_List_FAQ
>>>
>>> opennms-devel mailing list
>>>
>>> To *unsubscribe* or change your subscription options, see the bottom of
>> this page:
>>> https://lists.sourceforge.net/lists/listinfo/opennms-devel
>>
>>
>> ------------------------------------------------------------------------------
>> Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
>> Discover the easy way to master current and previous Microsoft technologies
>> and advance your career. Get an incredible 1,500+ hours of step-by-step
>> tutorial videos with LearnDevNow. Subscribe today and save!
>> http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Please read the OpenNMS Mailing List FAQ:
>> http://www.opennms.org/index.php/Mailing_List_FAQ
>>
>> opennms-devel mailing list
>>
>> To *unsubscribe* or change your subscription options, see the bottom of
>> this page:
>> https://lists.sourceforge.net/lists/listinfo/opennms-devel
>>
>
>
> ------------------------------------------------------------------------------
> Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
> Discover the easy way to master current and previous Microsoft technologies
> and advance your career. Get an incredible 1,500+ hours of step-by-step
> tutorial videos with LearnDevNow. Subscribe today and save!
> http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> Please read the OpenNMS Mailing List FAQ:
> http://www.opennms.org/index.php/Mailing_List_FAQ
>
> opennms-devel mailing list
>
> To *unsubscribe* or change your subscription options, see the bottom of this
> page:
> https://lists.sourceforge.net/lists/listinfo/opennms-devel
------------------------------------------------------------------------------
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
_______________________________________________
Please read the OpenNMS Mailing List FAQ:
http://www.opennms.org/index.php/Mailing_List_FAQ
opennms-devel mailing list
To *unsubscribe* or change your subscription options, see the bottom of this
page:
https://lists.sourceforge.net/lists/listinfo/opennms-devel
