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