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
Done: # tools/build/setnextversion.sh -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] http://markmail.org/message/qkkxycablpsmogsx > >[2] https://issues.apache.org/jira/issues/#?filter=12324570 > > > > > >Thanks > >Animesh > > > >