Good question. The purpose of milestones and criteria are primarily to answer the question “are we on track to ship <X> by <Y>”. So if we hit FL and some important features have not yet landed, we know we are no longer on track to ship everything by the intended date. We can either drop those features, or extend the timeline. We should not just keep plowing forward, hoping we can magically make up time later when we’re already underwater. Any exceptions to FL criteria should be extremely rare and no exceed more than a week or two past FL. Otherwise the FL milestone becomes pretty meaningless.
I don’t think its realistic to pick one strategy as the 100% solution, because it will really depend on the importance of a given features vs the importance of hitting in-market dates. Likewise for FC, if we hit that with 3 blockers remaining we probably will accept the risk and assume we are largely on track. If we hit it with 30 blockers, then we know we are not on track to ship as planned… and will have to make tradeoffs there in terms of timeline, next release scope and scope/quality. Lucas. On May 1, 2014, at 6:58 AM, Kartikaya Gupta <[email protected]> wrote: > 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 _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
