cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Prasanna Santhanam <>
Subject Re: non-committer workflow
Date Wed, 01 Aug 2012 12:56:38 GMT
On Wed, Aug 01, 2012 at 08:42:51AM -0400, Rohit Yadav wrote:
> On Aug 1, 2012, at 5:46 PM, Wido den Hollander <> wrote:
> > On 08/01/2012 04:50 AM, Alex Huang wrote:
> >>> So currently, there are three ways for a patch to be received:
> >>> 1. Email (see the workflow Wido proposed) 2. Reviewboard 3. Submitted
> >>> with a bug.
> >>> 
> >>> Email and ReviewBoard are the most visible, and it seems most people are
> >>> using ReviewBoard rather than email.
> >> 
> >> We should remove the email and submit with a bug options.
> >> 
> > 
> > Are you sure? For larger patches I agree that e-mail isn't that easy, 
> > but it seems to work with various other projects.
> > 
> > I personally like e-mail and 'hate' all kinds of various systems where I 
> > have to log in with different credentials.
> I totally agree with Wido, besides the review board workflow has a serious ownership
> When I submit a git formatted patch it would strip the commit
> message and author info, signature and retain only the unified diff.
> The reviewer and/or committer have to do the extra work of
> downloading the patch, applying/verifying it and then committing it.
> During the process they may change the original commit message and
> author signature (and they lose their ohloh points :)
> Further, the contributor is then required to go back and close the
> submission. Well one can use their mailbox from where they can
> import the patches, git am works. Or when the committer is
> downloading the diff anyway, why not download the actual git
> formatted patch emailed by an author and git apply? Just a
> suggestion.

This was tried in the past and backfired when non-committers send
through patches that get formatted by mail clients and have CRLF
issues when applied by the committer. 

I agree Reviewboard has extra workflow involved but it integrates the
review comments closely with the mailing list so it isn't as different 
from patches in the email in my opinion. It additionally provides
pretty diff tools online. If not I would have to put the patch through
my own diff tool.

The current pain points as I see are :

1) ReviewBoard removes the author information from the diff
2) git am doesn't always work
3) extra workflow step of submitter closing the patch request

These probably should be addressed by tooling.

> > 
> > If somebody finds a typo or small bug, should they really go through all 
> > the hoops for submitting a small patch?
> > 
> > Imho that shouldn't be necessary.
> > 
> > Wido


View raw message