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. 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. 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). 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. -Sebastien
