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
