On Thu, Apr 11, 2013 at 02:50:02PM -0700, Animesh Chaturvedi wrote: > Based on the community discussions of having 4 month cadence I am proposing > the following schedule: > > ============================= > 4.2 detailed schedule proposal: > ============================= > > > 2013-05-31 > Feature Freeze > All new feature need to have been merged into master by this date. > Release branch will be cut on this date. > Jenkins updated to include new release branch builds. > > 2013-06-01 through 2013-06-30 > Testing/Bug Fixes (testing against jenkins artifacts) > Documentation Finalization > > 2013-06-30 > Docs Freeze (except release notes and translations) > Release Branch moves to limited updates only (only commits allowed > in would be release blockers fixes, translation updates, etc...) > > 2013-07-01 through 2013-07-22 > Translation Development and Integration (should be ongoing, but > focused effort) > Final regression testing / bug fixes / doc fixes > > 2013-07-22 > 4.2.0-RC1 is created, and project level VOTE is called >
+1 to the plan above. > > I want to call out my concern on technical debt we have accumulated so far. > > I did an analysis on JIRA bugs yesterday night PST on "Affects Version = > 4.1" and created since Dec 2012 > > Total records : 429 > Resolution Type (Invalid, Duplicate, Cannot reproduce etc.) : 87 (30 > Blockers, 27 Critical, 27 Major, 4 Minor) > Valid Defects : 429-87= 342 > Fixed : 246 (60 Blockers, 70 Critical, 99 Majors) out of which 217 were fixed > since Feb > Unresolved : 96 (1 Blocker, 8 Critical, 64 Major) > > With this data it looks like we have fixed 2/3 of valid defects in little > over 2 months and pretty much deferring around 1/3 rd of issues for future > release. > > I also looked at overall backlog of bugs (Critical, Major and Blockers only) > as of 4/10/2013 - 10:0PM PST. > > 284 open (18 Blocker, 38 Critical, 228 Major) ; > By Fix version > - Release 4.0.x and prior: 13 > - 4.1: 70 > - 4.2 : 97 > - Future: 8 > - No version: 107 > > Looking at that we fixed 217 bugs in roughly 2 months during 4.1 cycle, > fixing the backlog of bug will probably take us 2 months. Should we extend > the 4.2 test cycle by 2 months [Original Schedule: 6/1 - 7/22, Extended > Schedule: 6/1-9/22] to reduce the technical debt significantly? I would like > to hear how community wants to address technical debt. Based on the input and > consensus I will publish the agreed schedule next week. > > I don't think that an extension of time changes bug counts really. IMO, we need to pull together to have some bug-fix focused effort applied to the code-base. It's also another reason that I'm so big on making sure that automated tests come in with the new features. That doesn't address test scenarios that human testers can come up with, but if a developer spends the time to think about testing the basic feature and codifies that, we should at least avoid the "this actually doesn't work at all" types of bugs. There's a school of thought that says, don't build another feature until you have sorted out the known bugs in the current features. I don't think we could really pull that off, but perhaps a different thread to rally people around the bug backlog is in order? -chip
