cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chip Childers <>
Subject Re: [ACS42] Release Status Update: After Code Freeze Next Steps
Date Thu, 01 Aug 2013 14:39:51 GMT
On Thu, Aug 01, 2013 at 04:13:14PM +0200, Wido den Hollander wrote:
> On 07/30/2013 09:25 PM, Animesh Chaturvedi wrote:
> >
> >Folks code freeze was on 7/29 and starting today we are moving ACS 42 into limited
updates in preparation for RC on 8/19. Code changes are now limited to fixes to blocker and
critical bugs only. I need to follow up on doc and translations.
> >
> >
> Shouldn't master now be bumped to 4.3?
> Wido


# tools/build/ -v 4.3.0-SNAPSHOT -b master

And edited deb/changelog

> >There is a tremendous effort going on since last couple of weeks to fix issues found
during the QA cycle. In last week alone 175 new issues were created and 250 were resolved.
The current unresolved issue count stands at 300+ with 60 blocker and critical.
> >
> >Given the high number of blocker and critical and that QA is still filing many defects
I will follow what Chip did for 4.1 [1]. Up until when we cut the first RC on (2013-08-19)
committers should continue to check in fixes to 4.2 branch for blocker and critical issues.
Please do any fixes as cleanly as possible (i.e., squash related commits and make sure to
avoid messy merge commits as much as possible).
> >
> >
> >For Contributors if you have a fix that needs to go into 4.2, please email the list
with the subject tag [ACS42] and note the review that contains the patch.  I'll pick whichever
I can, but will also rely on others with commit rights to make it efficient.
> >
> >I will review all commits going into that branch, and will revert anything that's
outside the scope of that I outlined above (unless there is a discussion and consensus on
this list to include something else).
> >
> >There are large number of issues that are resolved but not verified yet. Given that
the number is huge  with over 300 blocker and critical we need to prioritize and verify the
ones that were returned by developers as ( Invalid, Incomplete, CanNotReproduce, Later, NotAProblem)
first.  I have created a filter [2] to facilitate identifying these issues. This is no way
means not to verify other issues but it is to close on the ones that have the most likelihood
of being reopened during verification.
> >
> >[1]
> >[2]
> >
> >
> >Thanks
> >Animesh
> >

View raw message