A patch management system is definitely very helpful, doing it in both places would be even better.
Kelven > -----Original Message----- > From: Fred Wittekind [mailto:[email protected]] > Sent: Wednesday, June 13, 2012 6:00 AM > To: [email protected] > Subject: Re: Patches review > > On 6/12/2012 4:01 PM, David Nalley wrote: > > On Tue, Jun 12, 2012 at 3:46 PM, Alena Prokharchyk > > <[email protected]> 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
