incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fred Wittekind <...@twister.dyndns.org>
Subject Re: Patches review
Date Wed, 13 Jun 2012 14:49:17 GMT
On 6/13/2012 10:25 AM, David Nalley wrote:
> On Wed, Jun 13, 2012 at 8:59 AM, Fred Wittekind <rom@twister.dyndns.org> wrote:
>> On 6/12/2012 4:01 PM, David Nalley wrote:
>>> On Tue, Jun 12, 2012 at 3:46 PM, Alena Prokharchyk
>>> <Alena.Prokharchyk@citrix.com> wrote:
>>>> I know it's been discussed in several email threads, but I would like to
>>>> initiate a separate discussion on what tool we should use for reviweing
>>>> the patches.
>>>>
>>>> Several people (including myself - using Outlook on Mac OS X Lion) have
>>>> been struggling already with applying email patches using "git am". Some
>>>> patches appear to be broken, email file import/save is different in
>>>> various email clients, etc. But the main disadvantage - there is no other
>>>> way to track patch flow history rather than gathering email by subject.
>>>> For instance, I would like to see the patch history in some centralized
>>>> place:
>>>>
>>>> * when patch was created
>>>> * who picked up the patch for the review and when
>>>> * what was fixed after first, second,...n review
>>>> * when the patch was merged to the mainstream.
>>>>
>>>> I think we should start using the official tool for that -
>>>> Gerrit/Reviewboard/etc.
>>>>
>>>> Please follow up with your suggestions and preferences.
>>>>
>>>> -Alena.
>>>>
>>>>
>>> Thanks for starting this - I have a thrice rewritten mail sitting in
>>> my drafts folder around this subject. Quick followup to voice some of
>>> my frustrations.
>>>
>>> We have a process today - and for a number of folks that has worked
>>> very well. I personally find it dead easy to grab patches from github
>>> (though our mirroring is currently non-functional since we have made
>>> the move to the ASF. ). There's also a certain class of folks that
>>> have have sent patches via email that were also easy to apply.
>>>
>>> However, a number of folks are sitting behind servers or services that
>>> actively break patches which has led to much gnashing of teeth here.
>>> While I don't care so much about MUA issues, I do desperately despise
>>> seeing MTAs breaking patches - and I spent around 4 hours last night
>>> trying to unbreak patches from 3 different developers that their MTA
>>> (all different) had made completely unusable.
>>>
>>> Where this really disturbs me is the barrier to participation. Working
>>> on CloudStack is a pretty large barrier to begin with. You have to
>>> understand the facet of CloudStack that you are working on, and then
>>> understand git.
>>>
>>> While many of us can work via email - and some of us (me included)
>>> even prefer it, I do worry about what the net effect is now that we
>>> say - git patches submitted this way are actively broken by exchange,
>>> appear to be broken by gmail, etc. I suppose we could push folks to
>>> use some external mail service that behaves properly, but it seems
>>> like an artificial barrier, and one that is largely out of the control
>>> of folks wishing to collaborate with us.
>>>
>>> I think there are potentially benefits to using some tool other than
>>> email down the road as well such as being able to have $test_suite run
>>> against any patch before a committer even gets to review it.
>>>
>>> Thoughts, comments, flames?
>>>
>>> --David
>>>
>> Personally, I've always submitted patches via attaching them to bug
>> reports.  Works well when I find a bug in something, don't have time to
>> wait on anyone else to fix it, so I fix it myself, attach it to a bug
>> report, and hope it's in the next release so I don't have to deal with
>> it again.  Works pretty good with most open source projects.
>>
>> Fred Wittekind
>>
> So I have seen a lot of folks who use this approach, but that
> typically means that the mailing list gets cced on every action in the
> bugtracker. (mailing lists are where everything happens in Apache
> projects) We are already on track to hit 1,000 messages on this list
> alone this month - are we sure we want to add Jira traffic to that
> volume?
>
> --David
>
If we don't use the project's bug tracker to track the progress of bugs
and there patches, doesn't that defeat the purpose of having it?

Keeping the patch file attachments in Jira would keep those file
attachments out of the mailing list (reduction of traffic), and we
wouldn't run into MTA/MUAs mangling them.

If someone makes a comment in Jira, then CCs the mailing list, that
isn't any more mailing list traffic than sending to the same thing to
the mailing list alone.

Fred Wittekind


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message