On Wed, Jun 13, 2012 at 10:49 AM, Fred Wittekind <r...@twister.dyndns.org> wrote: > On 6/13/2012 10:25 AM, David Nalley wrote: >> On Wed, Jun 13, 2012 at 8:59 AM, Fred Wittekind <r...@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.prokharc...@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
Those are compelling arguments. --David
