Can you also specify what happens in the "failure" cases?
For example, what happens if we find so many blockers that 6 weeks after FC, we still have a nonzero number of blockers left? Do we extend CC, or do we ship with blockers? Or do we just pull the release and tell everybody to wait for the next one? I don't think it makes sense to specify an inevitable time-based constraint ("6 weeks after FC") along with a when-its-done constraint ("zero blockers").
Similarly, if we are 6 weeks past FL, and features aren't complete, do the features get pulled? Does the build not get sent to the chipset vendor? And so on.
In practice as developers we may need to build extra things into the code such as feature switches or work on parallel branches depending on what happens in the failure cases, so it's important to decide this ahead of time and make sure everybody is on the same page.
Cheers, kats On 30/4/2014, 18:35, Lawrence Mandel wrote:
I'd like to share some changes to the release milestones for B2G 2.0. Our intention is to get to a predictable release schedule with a defined path to shutdown development of a release. Additional work will happen to define the General Availability (GA) milestone and how we can effectively work with our partners to support their test cycles while meeting Mozilla's needs to work on newer releases. I know that we've been through a number of milestone/schedule changes in the past. This naturally begs the question why will this time be different? We have put in place tracking and criteria in order to have meaningful conversations about the progress of the release early and often. (These conversations will happen at least weekly starting at week 2 in the cycle.) The point of these conversations is to identify issues and take corrective action early. Below is the short version of the milestone definitions and a link to the longer version on the wiki. There is also a simple mapping of previous milestones and how they roughly map to the 2.0 milestones. The short version: FEATURE LANDING (FL) 6 weeks after development starts all feature work must be complete by the this date this milestone marks the beginning of the stabilization phase of the release STRING FREEZE target is FL with minimal string changes landing after FL FEATURE COMPLETE (FC) target 6 weeks after FL hard cut off for feature work FL exceptions requires QA sign-off indicates the build is ready for chipset vendor testing CODE COMPLETE (CC) target 6 weeks after FC zero blockers left from Mozilla and chipset vendors indicates the build is ready for OEM/ODM testing The longer version: https://wiki.mozilla.org/Release_Management/FirefoxOS/Release_Milestones Rough mapping of previous milestones: 2.0 FL = 1.4 FC 2.0 FC = 1.4 RTP 2.0 CC = 1.4 CF 2.0 GA = 1.4 TA Please respond to dev-b2g with questions. Lawrence
_______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
