Patch review for OpenLMI

Stephen Gallagher sgallagh at redhat.com
Tue Mar 12 11:31:50 UTC 2013


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue 12 Mar 2013 04:11:03 AM EDT, Jan Safranek wrote:
> On 03/11/2013 07:47 PM, Stephen Gallagher wrote:
>> I'm inclined to suggest that we take the following approach: 
>> Patches are sent to the openlmi-devel list as attachments. If 
>> another developer reviews it and replies with "Ack", it can be 
>> pushed immediately.
> 
> I'd rather wait for the review tool to be online, it may have 
> different workflow than sending patches to -devel and IMHO we 
> should avoid changing the workflow just in few days.
> 

I agree. I'll try to get back to focusing on this as soon as the
Fedora Alpha Freeze chaos is over.

>>> @sgallahg, you mentioned some review tool, what was it and 
>>> where/when/how can we use it?
>> 
>> 
>> The review tool I was talking about was Review Board[1], and I'm
>>  working on getting an instance of it hosted. I was planning to 
>> launch it in an OpenShift instance today, but I'm having some 
>> issues with their hosting (it looks like all of the static data 
>> like the CSS isn't properly reachable, so it looks terrible).
>> 
>> I will sort this out and provide an update as soon as possible.
> 
> I am not sure I get it right, it seems the patches must be manually
> uploaded using their post-review cmdline tool (ok) and when the
> patches are accepted, they must be manually checked in the upstream
> git. I.e. I still need to merge my topic branch with master and
> push it?
> 
> I know lot of projects use Gerrit, I have no personal experience 
> with it, but it seems more git-friendly. Still, does anyone have 
> actual experience with Review Board or Gerrit?
> 

First, a bit of disclosure: I've been an intermittent developer on the
Review Board project for about three years. I have a lot of
familiarity with it and I'm collaborating with upstream on enhancing
its git workflow capabilities. That being said, its current interface
is not designed for commit/merge workflow the same way that Gerrit or
Github are, but that's intentional. Handling merges is a complicated
bit of business and Review Board is focused on the review workflow
rather than the commit workflow.

I've used Review Board, Gerrit and Github on multiple occasions, and
without any doubt I will say that Review Board has the most
comprehensive, powerful and easy to use *review* interface. Gerrit has
the best merge interface (and a terrible review interface) and Github
is kind of mediocre on both points.

There is work in Review Board upstream right now targeted at their 2.0
release to support more of the git workflow pieces like pull requests
and merges. They *are* coming, and when it lands, I fully expect
Review Board at that point to be a clear advantage over Gerrit (along
with fully integrated with Github; the work going into the
patch-series and merge handling is planning to be able to use Github's
public API)


So yes, if we opt for Review Board, we're still going to be doing
manual merges to the upstream repository. I don't necessarily think
that's a bad thing, since it requires a final manual step to make sure
that nothing obviously breaks (although this can be minimized with
continuous integration testing).


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlE/EiYACgkQeiVVYja6o6NK7wCePgXSaHLsk9L3FeBD5NEUzWic
2F4AoIr2M77fxyUoyy/HFEepOF8Miwmh
=5/Ud
-----END PGP SIGNATURE-----


More information about the openlmi-devel mailing list