incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wido den Hollander <w...@widodh.nl>
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 <wido@widodh.nl> 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
issue:
>>
>> 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?

Wido

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


Mime
View raw message