cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chip Childers <chip.child...@sungard.com>
Subject Re: Branch Merge Expectations - Draft for Discussion
Date Fri, 22 Feb 2013 01:49:47 GMT
On Fri, Feb 22, 2013 at 10:40:38AM +0900, Dave Cahill wrote:
> 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.

+1 to that.  It's been quite difficult to work with master recently.
I've heard from several people (off list) that are quite
frustrated with the fact that master doesn't seem to be respected as a
shared tree that we should keep stable.

I'll update that page.

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