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
