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
