[This is a slightly cropped version of an email that went out on internal lists. The only thing removed is a few partner-related dates.]
Hi All, First off, we've decided to call the next FirefoxOS release (previously called v1.5) our v2.0 release. Note that this in and of itself doesn't mean any process changes, it's mainly a naming thing. There will be a follow-up email discussing the feature set we're targetting which hopefully will make it clear why we're calling the release 2.0. We'll be discussing this schedule on 9am PST gaia meeting on tuesday, as well as the coordination meeting 5pm PST meeting also on tuesday. Feedback there is very much encouraged. Here's the schedule that we've discussed and cleared internally and with partners: Mar 17 - April 28: Stabilization for 1.3T/1.3/1.4 April 29: Official "dev start" for 2.0 April 29 - June 8: 2.0 development June 9: 2.0 branch date June 9 - July 21: Stabilization for 2.0 July 22: Official "dev start" for 2.1 Since it's important to understand what these various dates mean, here's a more detailed explanation: Mar 17 - April 28: Stabilization for 1.3T/1.3/1.4 This time is intended for fixing any critical bugs that come up. I.e. bugs that we find during our and partner testing. If you don't get any 1.3T/1.3/1.4 bugs assigned to you in this time period, please do start on 2.0 work. This can either be new features, or working on the "top 25" backlog items of technical debt. It's up to each team to do the tradeoff between technical debt, polish and creating a product that's joyful to use vs. adding new features. However since we know that we will be finding plenty of 1.3T/1.3/1.4 issues, keeping this time scheduled for those releases allows us to keep a more realistic schedule. April 29: Official "dev start" for 2.0 This date mostly exists to help our planning. No actual rule changes happening on this date. The rules both before and after April 29th is that 1.3/1.4 bugfixing is highest priority, and 2.0 development comes after that. This date also works as a useful checkpoint. If your team still has a long list of blockers for 1.3T/1.3/1.4 then we should immediately reasses if we should move some of the 2.0 targetted features to a later release. The flip side of this is of course that we need to get better at finding bugs earlier. Bugs that we don't find until after this date is problematic. We're working with QA and partners to try to get bugs to developers earlier. April 29 - June 8: 2.0 development Development happens on m-c and gaia-master. Throughout this we should aim to have a policy of "no known regressions". I.e. if a patch to implement a new feature lands, but the feature is buggy or it breaks other things, then it should be immediately backed out or disabled. The goal is that by the end of this period the 2.0 development should be done. I.e. it's not enough to have landed enough patches to get the feature mostly working. We should aim to always keep m-c/gaia-master to be of release quality as best we can. Whenever something isn't working quite as it should, it slows down other developers. When landing big new features, please consider landing them turned off by default until they have gotten wider testing and are of sufficient quality to be turned on. This also means that you'll want to have your initial feature landings happening a week or two before June 8 so that any followup work can be done before June 8th. If you have a big new feature or refactoring patch that's ready just a few days before June 8th, consider waiting to land it, or waiting to turn it on, until after June 8th so that it goes into the next release instead. It's better to make big changes early in the next release, than late in this one. June 9: 2.0 branch date Gaia 2.0 branch created. Mozilla-central goes to aurora branch. Actual branching happens sometime during the 9th pacific timezone, so if you want to make sure to have your patches in the 2.0 release it needs to land on the 8th or before that. Joint triages begin. Soft String freeze, try to get all strings landed before this date. Anything beyond this should have the "late-l10n" keyword. Beyond this date we will be restrictive about what gets uplifted to the 2.0 release. So don't count on your patches getting uplifted if it's not for a blocker. This applies both to gaia and gecko patches. June 9 - July 21: Stabilization for 2.0 The top priority is to help out with the 2.0 release. That doesn't just include bugs that for sure are in your code. It also includes helping out with understanding bugs that we don't know what they are caused by. And of course if you can spend time on helping other teams that are overwhelmed with blockers, then that will help the project a lot. However if you don't have any blockers, and you can't effectively help if you don't have any critical bug work to do, then feel free to start on 2.1 development, or do code maintenance, or write more tests. July 22: Official "dev start" for 2.1 Like with April 29, no actual rule changes on this date, it's mostly here for planning purposes. That's it! If this goes well the plan is continue on this schedule for future releases. One thing of note is that we'll only be able to stick with this schedule if we also stick to the feature scope that set out to at the beginning of the release. I.e. any new features that we try to add later in the release adds significant risk. This risk increases the closer to the branch date on June 9th that we get, and is particularly true for new features requests that come in after the branch date. Such features make planning much harder both for us and our partners, and puts both the 2.0 release and the 2.1 release at risk. So please try to make sure that any new features or quality improvements that you want over what 1.4 has are raised as soon as possible. Other types of exceptions to this process might also happen. These exception always represent risk and so we'll do our best to avoid it, but we can't guarantee that it won't happen. / Jonas _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
