Well, I think we should always treat the status of blocker that way. Something is a blocker if we feel it blocks us from releasing. Not just in this stage but always. (I think I am repeating myself a tad) In fact I feel we must treat those 90 critical issues the same way and I dare not start to think about all the other bugs of lower prios.
On Wed, Jun 11, 2014 at 11:11 PM, Mike Tutkowski <mike.tutkow...@solidfire.com> wrote: > I agree - at this stage in the release, each blocker that remains should be > decided on a case-by-case basis if we still feel it is a blocker. > > > On Wed, Jun 11, 2014 at 2:54 PM, Alena Prokharchyk < > alena.prokharc...@citrix.com> wrote: > >> >> >> On 6/11/14, 1:45 PM, "Daan Hoogland" <daan.hoogl...@gmail.com> wrote: >> >> >I agree, but I wouldn't pin 'blocker' by a definition of the nature of >> >the defect. A blocker is something that blocks the community at large >> >from releasing. What you define here would be useful for more vague >> >prio definitions like 'critical', though. Of course a major defect in >> >any of the hypervisor - or network - or storage types can be >> >considered a blocker. But also they might not as they might have work >> >arounds. >> >> >> > A blocker is really something that we should decide on on a >> >case by case basis, in my opinion. >> >> Agree, especially at this stage of the release. >> >> > >> >On Wed, Jun 11, 2014 at 10:38 PM, Alena Prokharchyk >> ><alena.prokharc...@citrix.com> wrote: >> >> I guess its time to define what qualifies to be called a blocker bug. Is >> >> blocker something that: >> >> >> >> 1) happens on all the setups? >> >> 2) blocks core features from executing >> >> >> >> Because I think that the bug happening on KVM only (lets say the vms >> >>fail >> >> to start = core feature), can be considered as a blocker although it >> >> happens just on a particular hypervisor/storage setup (niche >> >>environment?) >> >> >> >> -Alena. >> >> >> >> >> >> On 6/11/14, 12:53 PM, "Daan Hoogland" <daan.hoogl...@gmail.com> wrote: >> >> >> >>>It is said by evil tongues in this mail thread that me, the RM does >> >>>not nag enough about the 4.4 branch status and the bugs marked to >> >>>apply to it. Worse; those evil tongues might just be right. In can >> >>>hereby say without reservation and with full heart and soul that I >> >>>will better my life in this perspect. >> >>> >> >>>With that of my chest I know that Hugo's mail was partially inspired >> >>>on my nagging about the following: I don't care if cloudstack explodes >> >>>and takes the earth and the moon down with it in its destruction, a >> >>>bug is not a blocker unless we on this list decide that it blocks us >> >>>from +1'ing a RC to be released. I do not say that critical issues >> >>>aren't possible blockers but that should always be discussed. Also all >> >>>this does not exempt us from triaging every bug down to trivial ones. >> >>>As I discussed with my other colleague, Ian, the chance is real that a >> >>>trivial bug is a blocker in someones niche environment with their >> >>>niche use-case. >> >>> >> >>>In fact I think that no one should alter the default prio of any issue >> >>>without discussing it on list. >> >>> >> >>>more nagging to follow, >> >>>Daan >> >>> >> >>>On Wed, Jun 11, 2014 at 8:36 PM, Nitin Mehta <nitin.me...@citrix.com> >> >>>wrote: >> >>>> But the blockers/criticals would keep coming unless its certified that >> >>>>the >> >>>> new features have been tested with some confidence and that the basic >> >>>> functionalities work. >> >>>> >> >>>> Thanks, >> >>>> -Nitin >> >>>> >> >>>> On 11/06/14 10:33 AM, "Mike Tutkowski" <mike.tutkow...@solidfire.com> >> >>>> wrote: >> >>>> >> >>>>>According to that list, we have four blockers remaining...all network >> >>>>>oriented. >> >>>>> >> >>>>>Murali Reddy has two. All four have an owner and presumably progress >> >>>>>is >> >>>>>being made. >> >>>>> >> >>>>>I guess it would be a good idea if we triaged critical defects and >> >>>>>determined once the blockers are done if any of those should be fixed >> >>>>>before an RC is built. >> >>>>> >> >>>>> >> >>>>>On Wed, Jun 11, 2014 at 11:28 AM, Pierre-Luc Dion <pd...@cloudops.com >> > >> >>>>>wrote: >> >>>>> >> >>>>>> Is there a list of issues, blockers, or todo items to be done in >> >>>>>>order >> >>>>>>to >> >>>>>> have 4.4 out ? The only things I saw is the list of blocker >> >>>>>>currently >> >>>>>> having 4 blocker ( >> >>>>>> >> >>>>>> >> https://issues.apache.org/jira/browse/CLOUDSTACK-6602?filter=12327112 >> >>>>>>) >> >>>>>> >> >>>>>> Does this mean that even if all blockers are fixed getting the >> >>>>>>branch >> >>>>>>4.4.0 >> >>>>>> able to build and be a workable CloudStack is a release manager >> >>>>>>nightmare? >> >>>>>> >> >>>>>> >> >>>>>> Pierre-Luc Dion >> >>>>>> Architecte de Solution Cloud | Cloud Solutions Architect >> >>>>>> 855-OK-CLOUD (855-652-5683) x1101 >> >>>>>> - - - >> >>>>>> >> >>>>>> *CloudOps*420 rue Guy >> >>>>>> Montréal QC H3J 1S6 >> >>>>>> www.cloudops.com >> >>>>>> @CloudOps_ >> >>>>>> >> >>>>>> >> >>>>>> On Wed, Jun 11, 2014 at 12:36 PM, Mike Tutkowski < >> >>>>>> mike.tutkow...@solidfire.com> wrote: >> >>>>>> >> >>>>>> > Yeah, I am concerned about 4.4 getting farther behind schedule, as >> >>>>>>well, >> >>>>>> > but I agree with David that we should not cancel it. >> >>>>>> > >> >>>>>> > I know it might be a pain, but I wonder if the RM would be willing >> >>>>>>to >> >>>>>> "nag" >> >>>>>> > people every few days (just an e-mail to dev@) about the current >> >>>>>>list >> >>>>>>of >> >>>>>> > blockers and their progress and to see if people need help and >> >>>>>>others >> >>>>>> might >> >>>>>> > be willing and able to do so. >> >>>>>> > >> >>>>>> > >> >>>>>> > On Wed, Jun 11, 2014 at 10:08 AM, David Nalley <da...@gnsa.us> >> >>>>>>wrote: >> >>>>>> > >> >>>>>> > > On Wed, Jun 11, 2014 at 11:30 AM, Hugo Trippaers >> >>>>>><h...@apache.org> >> >>>>>> > wrote: >> >>>>>> > > > Hey all, >> >>>>>> > > > >> >>>>>> > > > I¹m getting somewhat concerned about the 4.4 release. We don¹t >> >>>>>>seems >> >>>>>> to >> >>>>>> > > be able to get the 4.4 branch in shape for a release candidate >> >>>>>>and >> >>>>>> > > meanwhile master is diverging further and further. We also know >> >>>>>>that >> >>>>>> once >> >>>>>> > > we hit the RC phase we will probably need a sizable number of >> >>>>>> iterations >> >>>>>> > to >> >>>>>> > > eventually ship the release. Based on past experience, if we >> >>>>>>keep >> >>>>>>up >> >>>>>> like >> >>>>>> > > this we will have another release that will actually be released >> >>>>>>way >> >>>>>> > after >> >>>>>> > > the feature freeze for the next release (July 18). Probably >> >>>>>>leaving >> >>>>>>us >> >>>>>> in >> >>>>>> > > the same bad spot for the next release. >> >>>>>> > > > >> >>>>>> > > > I tried to come up with a number of solutions that could >> >>>>>>rectify >> >>>>>>the >> >>>>>> > > situation and help the release move forward, but i can¹t think >> >>>>>>of >> >>>>>>any. >> >>>>>> > Save >> >>>>>> > > for some options that might be considered extreme ideas. One the >> >>>>>>the >> >>>>>> more >> >>>>>> > > prominent ideas in my mind at the moment is skipping the 4.4 >> >>>>>>release >> >>>>>> all >> >>>>>> > > together and combine it with the next planned release (whether >> >>>>>>its >> >>>>>>5.0 >> >>>>>> or >> >>>>>> > > 4.5). This would require a community effort to focus on quality >> >>>>>>in >> >>>>>>the >> >>>>>> > next >> >>>>>> > > month and basically freeze the master for features and have a >> >>>>>>community >> >>>>>> > > wide push for quality to get the next release out on schedule. >> >>>>>> > > > >> >>>>>> > > > But before i go on and shout out even more drastic ideas, what >> >>>>>>do >> >>>>>>you >> >>>>>> > > think about the current 4.4 release. How close do you feel that >> >>>>>>we >> >>>>>>are >> >>>>>> to >> >>>>>> > > having a releasable product? >> >>>>>> > > > >> >>>>>> > > >> >>>>>> > > So this sounds very familiar to a discussion we had in 4.1 or >> >>>>>>4.2 >> >>>>>> > > timeframes. (I may have even been one of the folks proposing >> >>>>>>similar >> >>>>>> > > ideas, I don't recall) >> >>>>>> > > >> >>>>>> > > To save you some reading I am -1 on the idea of canceling 4.4. >> >>>>>>(though >> >>>>>> > > really - anyone can propose a release and ask for votes, we have >> >>>>>> > > adopted a bit more rigor, but that structure isn't demanded.) >> >>>>>> > > >> >>>>>> > > Here's the issues I see: >> >>>>>> > > 1. We set the expectation that 4.4 is coming; people worked hard >> >>>>>>to >> >>>>>> > > get features in, and our users are waiting on it. >> >>>>>> > > 2. We may not be perfect from a schedule perspective, but giving >> >>>>>>up >> >>>>>>on >> >>>>>> > > a release is a pretty negative thing to do - whats the reaction >> >>>>>>going >> >>>>>> > > to be? >> >>>>>> > > 3. Do you think we are in a position to make 4.5 any better? >> >>>>>>Speaking >> >>>>>> > > very frankly, I worry that we are not. I don't think that we >> >>>>>>have >> >>>>>> > > either the tooling or the social desire at present to make >> >>>>>>significant >> >>>>>> > > strides here. We don't dictate the priorities for individual >> >>>>>> > > developers. It might be a different story if we were in a >> >>>>>>corporate >> >>>>>> > > shop and could control what folks work on, it might be a >> >>>>>>different >> >>>>>> > > story. >> >>>>>> > > >> >>>>>> > > --David >> >>>>>> > > >> >>>>>> > >> >>>>>> > >> >>>>>> > >> >>>>>> > -- >> >>>>>> > *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>* * >> >>>> >> >>> >> >>> >> >>> >> >>>-- >> >>>Daan >> >> >> > >> > >> > >> >-- >> >Daan >> >> > > > -- > *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>*™* -- Daan
