As you know, we are nearing the end of the 1.3 feature window. We would like to
carefully vet any feature that lands in the last days of the window. If your
feature is ready, stable and performant, please coordinate with the drivers
team to land it. If you have concerns about the stability of the feature, and
its not a committed feature, we suggest you postpone it to the 1.4 feature
window, which is about to open.
Why?
We recently switched to a time-scoped release model. Each 3 months feature
window is followed by a 3 months stabilization window, which overlaps with the
subsequent feature window. For 1.2 it took us almost an entire 3 month cycle to
stabilize the release because we landed a lot of features in the 1.2 feature
window that weren't ready yet. That effort took away a lot of attention from
the 1.3 release. We wanted to avoid that this time, hence the request to
carefully vet all remaining 1.3 feature landings.
Why time-scoped releases? ("trains")
For those of you who have been with the project for a while, you probably
remember (and dread) the 1.0 and 1.1 releases. It was quite a grind because we
had a fixed timeline ("must be done by this date"), a fixed scope ("must do all
of this"), and a fixed team ("only have this many people"). This is called the
software engineering Trilemma, and its a pretty stressful experience for
everyone.
We switched to time-scoped releases to avoid getting back into this situation.
The product team is working hard to make sure that we only have very few
must-have features for every release ("committed features"). The vast majority
of features are "targeted". Features for both of these categories are chosen by
each team. Instead of us telling you how much you have to get done, we ask you
how much you think you can get done. And we are trying to give you room in case
your feature ends up taking longer than you thought. We want you to go fast and
not have to pad for the fear of deadlines. We ask you to get that list done if
you can. If you have concerns about the stability of a targeted feature, you
can punt it to the next release. This way we don't have to fix it under time
pressure. Just do it in the next feature window. Once we are past the feature
window and in the stabilization window, deadlines kick in. We can't slip the
end of the stabilization window. So if something isn
't stable, its much better to finish it in the next window, which buys you
another 3 months without deadline pressure.
Similarly, if you get more stuff done than you thought, thats perfectly fine,
too. Anything you land on trunk before the feature freeze that is stable and
performant can ride the next train, whether it was planned for that train or
not. The train model gives each team maximum flexibility and control over their
work!
So far, for each release you delivered pretty much all committed and targeted
features, and for 1.2 and 1.3 we actually landed many more features than we
planned. Our feature velocity is really great. Lets make sure we can match it
with solid stability and quality to reduce the time we have to work on
stabilizing each branch.
Let me know if you have any questions!
Thanks,
Andreas
_______________________________________________
dev-b2g mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-b2g
