Sounds reasonable That being the case, do we feel we can build a first RC once our remaining blockers are completed?
On Wed, Jun 11, 2014 at 3:19 PM, Daan Hoogland <daan.hoogl...@gmail.com> wrote: > 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 > -- *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>*™*
