Oh, and to be clear, I don't think anyone is criticizing Animesh's efforts. He does a great job of keeping track of defect trends and informing the community.
Let me provide an example for how we did this at HP/LeftHand, which is where I worked on a clustered SAN technology for seven years before joining SolidFire. As the release progresses, the window closes on lower-priority defects (I believe we do the same thing on CS). Once we got to a certain point in the release cycle, no changes could go in without agreement from the release stakeholders (the bugs were tracked and discussed on a bi-weekly basis). The RM was part of this process, but certainly not the person who decided in the end what should and shouldn't be allowed in at this stage of the game: There were representatives from development, test, support, and marketing involved in those decisions. The RM mainly facilitated the discussions. Now...how would we do that given our environment (mainly e-mail) with CloudStack? Perhaps a weekly e-mail toward the end weeks of the release where people could read about the issues they're interested in in detail and chime in on the ones they have knowledge of (saying how important or not a fix is for the given release, what the risks are, etc.)? On Tue, Sep 10, 2013 at 4:28 PM, Mike Tutkowski < mike.tutkow...@solidfire.com> wrote: > Yep, I agree it's a tight schedule. Whether or not that's a good idea is > beside the point, I suppose. > > I also agree some last-minute changes will come in. I was simply pointing > out that I have never encountered over 200 fixes coming into a release in > the final couple weeks. On a project where regression tests (hopefully > almost all automated) cover most all of the system, I expect such a high > number of last-minute changes would be OK. > > That being said, the schedules for projects I've been involved in prior to > CloudStack have been more on the order of 6 - 12 months, where QA has > literally months to perform regression testing and bug fixes trickle in > very slowly during that time frame. > > Since this is a different environment and I am not all that familiar with > how we churn out releases, I decided not to vote because I - like Daan - do > not have a good feel for the overall quality of the release. > > Thanks > > > On Tue, Sep 10, 2013 at 4:11 PM, Chiradeep Vittal < > chiradeep.vit...@citrix.com> wrote: > >> The process is laid out. There's exactly 2 months of testing/bug fixing. >> Given that schedule it isn't unreasonable that there are last minute >> fixes. >> Since the release manager is not an expert on any one feature, >> he/she cannot judge which fixes should/shouldn't make it into the release. >> >> The RM only has the list of open bugs and the RC date to make a decision! >> >> The voting requirements aren't as onerous, I hope all committers have read >> this: >> https://cwiki.apache.org/confluence/x/-oTlAQ >> >> >> >> On 9/10/13 1:55 PM, "Mike Tutkowski" <mike.tutkow...@solidfire.com> >> wrote: >> >> >Hi Sebastien, >> > >> >Personally I felt like I just didn't yet understand our testing/QA >> process >> >enough to know if 4.2 was ready or not. >> > >> >I did voice concerns over the past few weeks regarding the number of >> >checkins that took place right before a RC was built (since I have never >> >on >> >any product I've worked on in the past 15 years experienced such a high >> >volume of fixes so late in the game). >> > >> >People did chime in both in agreement and also to try to soothe my >> >concerns. >> > >> >In the end, I just wanted to wait and see how this process plays out, so >> I >> >didn't feel I should cast a vote. >> > >> >I hope that clarifies my thinking here. >> > >> >Thanks >> > >> > >> >On Tue, Sep 10, 2013 at 2:48 PM, Sebastien Goasguen >> ><run...@gmail.com>wrote: >> > >> >> I am changing the subject of the [RESULTS] thread for the 4.2 release. >> >> >> >> On Sep 10, 2013, at 4:12 PM, Animesh Chaturvedi < >> >> animesh.chaturv...@citrix.com> wrote: >> >> >> >> > >> >> > >> >> > The vote has *passed* with the following results (binding PMC votes >> >> indicated with a "*" next to their name: >> >> > >> >> > +1 : Edison*, Chiradeep*, Sebastien*, Prasanna*, Rajesh Batala, Ove >> >> Ewerlid >> >> > -1 : Marcus*, Chip*, Simon Weller >> >> > >> >> >> >> FWIW, I am very disappointed by this vote. The result does not matter, >> >>the >> >> number of people voting is worrisome to me. >> >> >> >> We have over ~70 apache committers on CloudStack, why didn't people >> >>vote ? >> >> >> >> -sebastien >> >> >> >> > I'm going to proceed with moving the release into the distribution >> >>repo >> >> now and work on release notes and other documentation tasks >> >> > >> >> > The -1 are recorded for the CLVM issue [1]. A fix for this issue is >> >> available and fixed in 4.2-forward branch and will be available for >> >>4.2.1. >> >> If anyone needs the fix now they can cherry-pick from 4.2-forward with >> >> commitId f2c5b5fbfe45196dfad2821fca513ddd6efa25c9. This issue will be >> >> release noted. >> >> > >> >> > >> >> > [1] https://issues.apache.org/jira/browse/CLOUDSTACK-4618 >> >> > >> >> > >> >> > Thanks >> >> > Animesh >> >> >> >> >> > >> > >> >-- >> >*Mike Tutkowski* >> >*Senior CloudStack Developer, SolidFire Inc.* >> >e: mike.tutkow...@solidfire.com >> >o: 303.746.7302 >> >Advancing the way the world uses the >> >cloud<http://solidfire.com/solution/overview/?video=play> >> >* * >> >> > > > -- > *Mike Tutkowski* > *Senior CloudStack Developer, SolidFire Inc.* > e: mike.tutkow...@solidfire.com > o: 303.746.7302 > Advancing the way the world uses the > cloud<http://solidfire.com/solution/overview/?video=play> > *™* > -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud<http://solidfire.com/solution/overview/?video=play> *™*
