> -----Original Message----- > From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] > Sent: Thursday, June 12, 2014 12:27 AM > To: dev > Subject: Re: [DISCUSS] Release 4.4 > > Why would we need that in a mail to dev@ Animesh? It is on the release > dashboard. [Animesh] I wish everyone would look at the dashboard but I think very few do.
As for the bulk edit; I like your style but I like to give each edit a > personal note. So I edit blockers asking specific questions. [Animesh] That’s fine but RM got limited time, If you can scale doing that I have no objection. > > On Thu, Jun 12, 2014 at 12:43 AM, Animesh Chaturvedi > <animesh.chaturv...@citrix.com> wrote: > > 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>*™* > > > > -- > Daan
