The mis-alignment is simply because before now, Cloud Services and Firefox were in different parts of the org, and we never coordinated a schedule of pushing web content with Firefox trains. The proposal is not to lead by a cycle, really. It's just to align our "chunks of work" into the same 2-week instances. We'll still be shipping every 2 weeks, versus Firefox trains shipping every 6.
On Tue, Jul 28, 2015 at 2:00 PM Nicholas Alexander <[email protected]> wrote: > > On Sun, Jul 26, 2015 at 5:50 PM, Ryan Kelly <[email protected]> wrote: > >> >> Hi All, >> >> >> For cross-team planning purposes, it makes sense for us to have our >> two-week development cycles aligned with those of the rest of the >> Firefox org. >> >> The broader org are scheduling work based on three two-week development >> iterations in each six-week Firefox release cycle. They're starting >> "iteration 42.3" this week, the third and final two-week iteration while >> Firefox 42 is on Nightly. >> >> We're halfway through our train-43 development cycle, meaning we're >> misaligned by a week. >> >> I propose that once train-43 is out the door, we do a three-week train >> to get into alignment: >> >> * Week of 3rd August: train-43 tagged, train-44 begins >> * Week of 10th August: train-43 deployed, Firefox 40 released >> * Week of 24th August: train-44 tagged >> >> This would put us squarely in alignment with the Firefox 43.X >> development cycles, like so: >> >> * Firefox 43.1 == FxA train-44 >> * Firefox 43.2 == FxA train-45 >> * Firefox 43.3 == FxA train-46 >> * etc... >> >> At which point we might consider just adopting their naming scheme as >> well, but let's not change too many things at once :-) >> >> It would also mean that we have our train *deployments* offset by a week >> from Firefox releases, unlike train-43 with is scheduled to go live the >> same week as the Firefox 40 release. I think this will be a good thing >> for overall release and quality management. >> >> >> Thoughts? >> > > As a client engineer who will care more and more about FxA trains and > features, I'm a big +1 to aligning; but the fact that deployment is > mis-aligned surprises me. I suppose what you're saying is that a web > feature that the client depends on will always *lead* by a cycle, not > *drag* by a cycle; i.e., that synchronized features will always be > developed in earlier web versions that precede client versions, so that the > deployment is always in advance of the moving client. Is that correct? > > Nick > _______________________________________________ > Dev-fxacct mailing list > [email protected] > https://mail.mozilla.org/listinfo/dev-fxacct >
_______________________________________________ Dev-fxacct mailing list [email protected] https://mail.mozilla.org/listinfo/dev-fxacct
