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>*™*
