[ACS41][QA] Bug fixing sprint?

[Chip Childers <ch...@sungard.com>]

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?

RE: [ACS41][QA] Bug fixing sprint?

[Animesh Chaturvedi <an...@citrix.com>]

+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.ponnaganti@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.childers@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?

RE: [ACS41][QA] Bug fixing sprint?

[Sudha Ponnaganti <su...@citrix.com>]

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.childers@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?