incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wido den Hollander <>
Subject Re: non-committer workflow
Date Wed, 01 Aug 2012 13:07:07 GMT
On 08/01/2012 02:56 PM, Prasanna Santhanam wrote:
> 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
>>>>> 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 think this happens when people attach their patches, but if you send 
them with "git send-email" they will go through just fine.

HTML mail clients and stuff make garbage of patches. That's why I'm 
again HTML e-mail on this mailinglist.

> 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

Again, I think because people did not use "git send-email"

> 3) extra workflow step of submitter closing the patch request
> These probably should be addressed by tooling.

Do you mean reviewboard tooling or tooling for patches through e-mail?


>>> 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