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