<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jul 26, 2015 at 5:50 PM, Ryan Kelly <span dir="ltr"><<a href="mailto:rfkelly@mozilla.com" target="_blank">rfkelly@mozilla.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Hi All,<br>
<br>
<br>
For cross-team planning purposes, it makes sense for us to have our<br>
two-week development cycles aligned with those of the rest of the<br>
Firefox org.<br>
<br>
The broader org are scheduling work based on three two-week development<br>
iterations in each six-week Firefox release cycle.  They're starting<br>
"iteration 42.3" this week, the third and final two-week iteration while<br>
Firefox 42 is on Nightly.<br>
<br>
We're halfway through our train-43 development cycle, meaning we're<br>
misaligned by a week.<br>
<br>
I propose that once train-43 is out the door, we do a three-week train<br>
to get into alignment:<br>
<br>
  * Week of 3rd August:  train-43 tagged, train-44 begins<br>
  * Week of 10th August: train-43 deployed, Firefox 40 released<br>
  * Week of 24th August: train-44 tagged<br>
<br>
This would put us squarely in alignment with the Firefox 43.X<br>
development cycles, like so:<br>
<br>
  * Firefox 43.1 == FxA train-44<br>
  * Firefox 43.2 == FxA train-45<br>
  * Firefox 43.3 == FxA train-46<br>
  * etc...<br>
<br>
At which point we might consider just adopting their naming scheme as<br>
well, but let's not change too many things at once :-)<br>
<br>
It would also mean that we have our train *deployments* offset by a week<br>
from Firefox releases, unlike train-43 with is scheduled to go live the<br>
same week as the Firefox 40 release.  I think this will be a good thing<br>
for overall release and quality management.<br>
<br>
<br>
Thoughts?<br></blockquote><br></div><div class="gmail_quote">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?<br><br></div><div class="gmail_quote">Nick<br></div></div></div>