To stick my oar in, I think that 3 days is too short a time for people to get round to doing meaningful testing, particularly for those of us doing it on a purely voluntary basis.
Also I got the feeling that we were spinning up new RCs before it was clear that all issues with the previous RC had been fixed and committed. Maybe a -1 has to be accompanied by a Jira ticket marked as a blocker. People should carry on testing an RC after it's vote has been cancelled and adding -1s and Jira blockers tickets, to avoid a new RC which is going to be -1ed immediately... Once the blockers are cleared we should be good to go for the next RC. Regards Paul Angus Cloud Architect S: +44 20 3603 0540 | M: +447711418784 | T: CloudyAngus paul.an...@shapeblue.com -----Original Message----- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: 04 March 2014 15:55 To: dev Subject: Re: 4.4 Feature Freeze Animesh, You are doing a great job as guard on our present release and I don't recall features slipping in either. instead those should now be added to the master branch. If Sebastien made it sound that way it is probably because of something else that is bothering him. However, Sebastien makes a very good point and I would go further. In my opinion we shouldn't be talking about how many months we keep between releases. If I make a new feature I want it scrutinized by all the guru's. Once they have nothing to nag about anymore it should be in in less then a month. We are a long way from that, but having to plan a feature in advance is never going to advance quality and instead will always be a constraint on it. I could make the finger pointing point as well; At Schuberg Philis we are dedicating a lot of effort to quality, both by tracking bug findings and by setting up an automated test environment. I would prefer to spend this energy in making nice features for the next release. There is seven of us now and I don't think we spend one seventh of our energy/time in new features over the last period. The next release is containing a bunch of features already that won't be stable from the get go anyway. let's make a good product before we make it greater. So, can we find common ground on this issue? My take, rather one feature per release (each week) with high quality and intensive testing then three features with divided attention to the code involved. This is not a proposal, yet. Just an illustration of my emotions. kind regards, Daan On Tue, Mar 4, 2014 at 1:45 PM, Sebastien Goasguen <run...@gmail.com> wrote: > > 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 > -- Daan Need Enterprise Grade Support for Apache CloudStack? Our CloudStack Infrastructure Support<http://shapeblue.com/cloudstack-infrastructure-support/> offers the best 24/7 SLA for CloudStack Environments. Apache CloudStack Bootcamp training courses **NEW!** CloudStack 4.2.1 training<http://shapeblue.com/cloudstack-training/> 18th-19th February 2014, Brazil. Classroom<http://shapeblue.com/cloudstack-training/> 17th-23rd March 2014, Region A. Instructor led, On-line<http://shapeblue.com/cloudstack-training/> 24th-28th March 2014, Region B. Instructor led, On-line<http://shapeblue.com/cloudstack-training/> 16th-20th June 2014, Region A. Instructor led, On-line<http://shapeblue.com/cloudstack-training/> 23rd-27th June 2014, Region B. Instructor led, On-line<http://shapeblue.com/cloudstack-training/> This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
