Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of sudha.ponnaganti@citrix.com
 designates 66.165.176.63 as permitted sender)
From: Sudha Ponnaganti <sudha.ponnaganti@citrix.com>
To: "cloudstack-dev@incubator.apache.org"
	<cloudstack-dev@incubator.apache.org>
Date: Mon, 11 Mar 2013 09:11:45 -0700
Subject: RE: [ACS41][QA] Bug fixing sprint?
Thread-Topic: [ACS41][QA] Bug fixing sprint?
Thread-Index: Ac4ecawvc7WTOolMTeiVvSn1dyIongAAJz5g
Message-ID: 
 <7914B38A4445B34AA16EB9F1352942F101435BEBAAAA@SJCPMAILBOX01.citrite.net>
References: <20130311160032.GZ98093@USLT-205755.sungardas.corp>
In-Reply-To: <20130311160032.GZ98093@USLT-205755.sungardas.corp>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Chip,
=20
+1 for bug sprint - However can this be extended to more of a week rather t=
han a day because 3/22 is date to cut RC1 [1]. With the given outstanding n=
umber of defects, I am afraid it would not be sufficient to close the relea=
se with decent quality in my opinion. Critical and Blockers should be close=
d by them. We can look at the major and defer the ones that are not necessa=
ry 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.=20

[1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+4.1+R=
elease

Thanks
/Sudha

-----Original Message-----
From: Chip Childers [mailto:chip.childers@sungard.com]=20
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 t=
hey go into the repo yet.

2 - Generally, I prefer to keep code "churn" to a minimum for release branc=
hes (i.e.: reduced number of commits in the branch), specifically so that r=
isk of regressions and / or new bugs being introduced is limited.

However, the positive side of doing something like this would be to help kn=
ock 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 qu=
ality yet):

8 Blocker
24 Critical
48 Major
23 Minor
1 Trivial

Any thoughts?