tb development process evolution
dmose at mozillamessaging.com
Wed Jun 23 00:46:44 UTC 2010
A number of us have talked recently about how it makes sense to evolve
the development process of Thunderbird to be able to both get better
results and move more quickly. Here's a summary of what I think came
out of those conversations:
* Much of our feature / front-end work is likely to happen in add-ons.
The intent is to do significant iteration there and get significant user
feedback before deciding whether or not we land it in the core (not to
mention when and how we do that landing). One consequence of this is
that we expect to have less feature work needing localization landing in
the core itself.
* We'd like to have frequent, regular releases that we use to get
significant feedback from users. The current thinking is that we'd try
and cut a new release after each landing of significant feature or
platform work. This could conceivably be as frequent as once every week
or two, though more likely it would be a less often than that. To do
this, we need a significantly lighter weight process than what we've
been using. We've speculated that we could, after each important
landing, pick a nightly that we think is good enough, and then spin a
branded alpha release based on that nightly.
* There would be little to no manual QA process for these releases.
Initially, we probably would have some, but we'll try and automate it
all away as quickly as possible.
* There would also be no localized builds for these alpha releases
(which is what Firefox does today).
* We'd like to be significantly more intentional about getting feedback
from all our channels than we have in the past (with the exception of
RC2). We'd do this by setting up an explicit contract around the
channels explaining what people sorts of risks and benefits users can
expect and what sort of feedback we're soliciting as well as by
experimenting with various mechanisms of explicitly requesting feedback
from users (surveys, GetSatisfaction, etc.).
* Once enough work stacks up in the tree that we decide we need or want
an end-user ship vehicle, we'd schedule one beta and one release
candidate. Each of these would be done with full l10n and more
traditional levels of QA.
Finally, we don't yet know whether the end-user next release vehicle is
likely to come off of a 1.9.3-based branch or a 1.9.2-based branch of
Do folks think this is likely to work and/or see significant issues that
we should think about before we try this?
More information about the tb-planning