+1 -----Original Message----- From: Alex Huang [mailto:alex.hu...@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: dcah...@midokura.jp [mailto:dcah...@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.chaturv...@citrix.com> wrote: > > > > > > > > -----Original Message----- > > > From: Marcus Sorensen [mailto:shadow...@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 <j...@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 > > > > j...@zonker.net > > > > Twitter: @jzb > > > > http://www.dissociatedpress.net/ > >
