On 6/11/14, 9:36 AM, "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. Good idea. Should we do the same for Critical bugs? What would be the RC criteria - no blockers, no criticals? We should also triage these bugs as sometimes even though they are filed as blockers, they are not really blockers (As Daan already pointed out in one of his previous emails) > > >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>**
