> -----Original Message----- > From: Sebastien Goasguen [mailto:run...@gmail.com] > Sent: Tuesday, March 04, 2014 4:45 AM > To: dev@cloudstack.apache.org > Subject: Re: 4.4 Feature Freeze > > > On Mar 3, 2014, at 8:18 PM, Animesh Chaturvedi > <animesh.chaturv...@citrix.com> wrote: > > > > > > >> -----Original Message----- > >> From: Sebastien Goasguen [mailto:run...@gmail.com] > >> Sent: Sunday, March 02, 2014 10:13 AM > >> To: dev@cloudstack.apache.org > >> Subject: Re: 4.4 Feature Freeze > >> > >> My take is that we are slipping on RC and re-voting because we are > >> forcing code into the release. > >> > > [Animesh] That is not right, for 4.3 I had called out feature freeze date > clearly and do not recall new feature added. IMHO the one challenge as > community that we have which has been raised earlier also is QA > contribution is primarily coming from one organization. Most other folks > start taking the release for a spin only after RC2/RC3 or so and then we see > additional issues and more re-spins. We really have to get all engaged in > testing much earlier in the cycle. Sudha used to call out for help on QA > activity but in prior releases I don't think she got much volunteers. We have > huge technical debt and that is not going to go away with pointing fingers. If > a specific scenario is benefiting someone as a user/developer of CloudStack > and it turns out is not guarded with automation sufficiently and regresses in > a release shouldn't the person using it also take some responsibility for > safeguarding it with automation? > > > > > Of course everyone is a stakeholder in making CloudStack a high quality > software. > > I am not pointing fingers at anyone I am just expressing my perception of > what is going on. I have seen several things lately where it seems that we > prefer to put half-baked features in a major release rather than wait. > > Say we release every 6 months, since releases are far apart this puts stress > on the developer to put his feature "in" before feature freeze, perhaps > sacrificing quality and testing. If we were to release more often then the > stress to "miss" a release would be alleviated. [Animesh] I need some more time to rationalize and put together mu thoughts on 6 months v/s 4 months. But my first priority is 4.3 so will come to it later > > I'd rather see/know that developers don't rush their features because they > know they can see it in less than 4 months then see features being added to > a release in fear of missing a cycle. > > The issue of QA is another one. Personally I'd like to start testing a release > branch once code has stabilized and I'd prefer to see a RM lock down on the > release before testing. [Animesh] As soon as we did the first RC I had created the forward branch and 4.3 branch checkins were not allowed What we have seen (and I'd be happy to be wrong), is > lots of code changes -a lot of times without bug ids- even after an RC was > out (even though this got corrected in the latest RC). [Animesh] I hate that too, I had called out to many folks that we need a bug ID for any cherry-pick.
When there is so much > churn on a release so close to an RC being cut it really is not conducive to > testing. Maybe the churn is not an issue, but imho I would like to see every > commit being with a bug ID and being a direct decision of the RM. [Animesh] Certainly once I have wrapped up 4.3 I will put a report for each RC to help us analyze how can we improve. Even during RCs most feedback came from only a few handful of people, may be other community members were testing but did not provide feedback but atleast from the data it does looks like testing involvement even during RCs is limited. Once we get a -1 on RC I think people holdback on testing and then next RC we find something else. > > -Sebastien
