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