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
