tb development process evolution

Dan Mosedale 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 
comm-central.

Do folks think this is likely to work and/or see significant issues that 
we should think about before we try this?

Other comments?

Thanks,
Dan



More information about the tb-planning mailing list