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>*™*
