cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sudha Ponnaganti <sudha.ponnaga...@citrix.com>
Subject RE: Branch Merge Expectations - Draft for Discussion
Date Fri, 22 Feb 2013 23:23:59 GMT
+1

-----Original Message-----
From: Alex Huang [mailto:Alex.Huang@citrix.com] 
Sent: Friday, February 22, 2013 2:18 PM
To: cloudstack-dev@incubator.apache.org
Subject: RE: Branch Merge Expectations - Draft for Discussion

Also I like to add a note about DB upgrades must be completed before the merge.

--Alex

> -----Original Message-----
> From: dcahill@midokura.jp [mailto:dcahill@midokura.jp] On Behalf Of 
> Dave Cahill
> Sent: Thursday, February 21, 2013 5:41 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: Branch Merge Expectations - Draft for Discussion
> 
> The one change I'd like here is to add a note about post-merge, as a 
> reminder to not "merge and run".
> 
> Testing comprehensively before merging should cover most issues, but I 
> think it's woth adding a note that you should plan to wait for Jenkins 
> builds to complete successfully before considering your work done.
> 
> On Fri, Feb 22, 2013 at 4:55 AM, Animesh Chaturvedi < 
> animesh.chaturvedi@citrix.com> wrote:
> 
> >
> >
> > > -----Original Message-----
> > > From: Marcus Sorensen [mailto:shadowsor@gmail.com]
> > > Sent: Thursday, February 21, 2013 9:02 AM
> > > To: cloudstack-dev@incubator.apache.org
> > > Subject: Re: Branch Merge Expectations - Draft for Discussion
> > >
> > > On Thu, Feb 21, 2013 at 9:40 AM, Joe Brockmeier <jzb@zonker.net>
> wrote:
> > > > On Wed, Feb 20, 2013, at 04:23 PM, Animesh Chaturvedi wrote:
> > > >> Do we really need to wait 72 hours for all merge requests? I 
> > > >> feel that slows developers down unless they plan very well.
> > > >
> > > > What's wrong with the expectation being that they plan very well?
> > > > ;-)
> > > >
> > > > Remember, "community over code." The point of waiting 72 hours 
> > > > is to give the community the opportunity to review, comment, etc.
> > > >
> > > > The point that some merges are less disruptive / intrusive than 
> > > > others is well-taken, though. Perhaps that is something that 
> > > > could be discussed during the feature proposal and decided then. 
> > > > If the community decides up-front that a merge is unlikely to be 
> > > > a problem, then maybe the expectation would be that only 48 or 
> > > > 24 hours needs to pass to allow for review & comments. But it 
> > > > should be explicit, and I'd rather err on the side of allowing 
> > > > the community
> time to review.
> > >
> > > I think the idea is that the people that a review would be 
> > > targeted at
> > are likely
> > > already involved, or perhaps review has been requested 
> > > independently
> > prior to
> > > formally requesting the merge. So the question is whether it's 
> > > necessary
> > to
> > > open up a 72 hour window where the general dev team has a chance 
> > > to
> > review
> > > the code, when presumably all of the people who care should be 
> > > involved,
> > if the
> > > feature is progressing properly. I'm not entirely sure.
> > >
> > [Animesh>] Marcus, thanks for clarifying my opinion is similar to yours.
> > Those who need to be involved should be engaged early on throughout 
> > the development. If we push MERGE request as the formal mechanism 
> > for the community to review and respond it may be too late and I 
> > doubt how much of that will happen even in 72 hours.
> >
> > > >
> > > > Best,
> > > >
> > > > jzb
> > > > --
> > > > Joe Brockmeier
> > > > jzb@zonker.net
> > > > Twitter: @jzb
> > > > http://www.dissociatedpress.net/
> >

Mime
View raw message