+1 Given that we have 35 critical and blockers it makes sense to aggressively close the defects by this week to meet the 3/22 RC date. I see all the 35 issues are assigned so if folks attend to their issues at priority we should get in better shape
Animesh > -----Original Message----- > From: Sudha Ponnaganti [mailto:sudha.ponnaga...@citrix.com] > Sent: Monday, March 11, 2013 9:12 AM > To: cloudstack-dev@incubator.apache.org > Subject: RE: [ACS41][QA] Bug fixing sprint? > > Chip, > > +1 for bug sprint - However can this be extended to more of a week rather > than a day because 3/22 is date to cut RC1 [1]. With the given outstanding > number of defects, I am afraid it would not be sufficient to close the release > with decent quality in my opinion. Critical and Blockers should be closed by > them. We can look at the major and defer the ones that are not necessary > and the rest can be fixed. Within the next 10 days, I think that can be > achieved. Also need to leave some room for incoming blockers. > > For Master may be 1 day a week should be fine. > > [1] > https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+4.1+ > Release > > Thanks > /Sudha > > -----Original Message----- > From: Chip Childers [mailto:chip.child...@sungard.com] > Sent: Monday, March 11, 2013 9:01 AM > To: cloudstack-dev@incubator.apache.org > Subject: [ACS41][QA] Bug fixing sprint? > > Hi all, > > Last week, Sebastian raised the question of doing a bug sprint for 4.1. > I'd like to see what people think about doing something like a 1 day sprint on > Tuesday of next week. > > I have a couple of concerns about doing this, which I'll explain below. > I'm not sure what the right answer is to addressing these concerns, but we > need to at least be aware of them: > > 1 - We will need to be very careful about 4.1 branch stability, especially > build > and unit test stability. Master has been having a rough time of it, and we > don't have tooling in place to ensure that commits are good before they go > into the repo yet. > > 2 - Generally, I prefer to keep code "churn" to a minimum for release > branches (i.e.: reduced number of commits in the branch), specifically so that > risk of regressions and / or new bugs being introduced is limited. > > However, the positive side of doing something like this would be to help > knock down our total bug count from it's rather high number. > > We currently have a pretty high bug count for 4.1 (certainly not release > quality yet): > > 8 Blocker > 24 Critical > 48 Major > 23 Minor > 1 Trivial > > Any thoughts?
