Yes we cannot cancel the release. IMHO we started the 4.4-forward branch way early. I had created the forward branch for 4.2 and 4.3 only after first RC because up until RC we have always seen a lot of code churn and I did not think RM can scale with all the cherry-picks given that RM has to focus on the big picture.
We need a daily list of blockers/critical I can set up a filter and subscription that will forward to dev mailing list automatically. We should also cc folks whom we are expecting to respond as we get lots of email on dev and follow up may not get noticed. One other thing that I used to do was setup a JIRA query for all the open Blocker and critical issues that have not been updated in last 7 day and do a BULK EDIT and ask for status or follow up. Thanks Animesh > -----Original Message----- > From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com] > Sent: Wednesday, June 11, 2014 9:37 AM > To: dev@cloudstack.apache.org > Subject: Re: [DISCUSS] Release 4.4 > > 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>*™*
