Confirmed users
2,615
edits
User:Dmose/Tb Post-3.0 Scratchpad: Difference between revisions
User:Dmose/Tb Post-3.0 Scratchpad (view source)
Revision as of 02:53, 24 November 2009
, 24 November 2009no edit summary
(Created page with '{{draft}} At the moment, this page is merely a scratchpad where I'm putting together ideas for post Tb3 work. Before any of the things here become real, I'll be iterating on th…') |
No edit summary |
||
| (9 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
{{draft}} | {{draft}} | ||
Part of the plan for Thunderbird is to move our development process in a more agile direction. Now that we've just about got Tb3 out the door, here are some process changes I propose to help us get there. Please post feedback on the wiki Talk page or to dev-apps-thunderbird@lists.mozilla.org. | |||
Part of the plan for Thunderbird is to move our development process in a more agile direction. Now that we've just about got Tb3 out the door, | |||
== Dev Cycle == | == Dev Cycle == | ||
| Line 19: | Line 17: | ||
* Shoot for one major release every 4-6 months, based on the closest appropriate [[Firefox/Roadmap]] release. | * Shoot for one major release every 4-6 months, based on the closest appropriate [[Firefox/Roadmap]] release. | ||
* Shoot for a milestone every 4 weeks (down from 8-10 in the Tb3 cycle). | * Shoot for a milestone every 4 weeks (down from 8-10 in the Tb3 cycle). | ||
Note that because this is significantly different than the way we've been working, it's clearly going to present some new challenges. In particular: | Note that because this is significantly different than the way we've been working, it's clearly going to present some new challenges. In particular: | ||
* More frequent releases are likely to add non-trivial QA & RelEng load | * More frequent releases are likely to add non-trivial QA & RelEng load | ||
* Sufficiently large features | * Sufficiently large features may sometimes be hard or impossible to segment into 4-6 month chunks | ||
* We | * We'll likely end up having to backport some patches to more than one branch, as Firefox and Gecko developers are doing today. | ||
The intent of the above proposal, therefore, is not to offer rules that must be followed, but rather to provide a general direction to work towards. The intent being to see how well we can make it work for us, and iterating on our process as we go. | The intent of the above proposal, therefore, is not to offer rules that must be followed, but rather to provide a general direction to work towards. The intent being to see how well we can make it work for us, and iterating on our process as we go. | ||
| Line 34: | Line 31: | ||
(I suspect we'll also want to sync up with the revised mozilla-central super-review process, but I think that can probably wait until after we get more critical stuff nailed down). | (I suspect we'll also want to sync up with the revised mozilla-central super-review process, but I think that can probably wait until after we get more critical stuff nailed down). | ||
== Thunderbird 3.1 == | |||
As the first concrete-step towards agility, I propose that 3.next should be a short-cycle release (~4 months) based on (very likely) 1.9.2. The intent of this release would be primarily: | |||
* Update to a version of Gecko further from end-of-life than 1.9.1 | |||
* Land almost-finished work that got cut from 3.0 | |||
* Opportunistically take high-value changes that leverage the platform work we've done in Tb3 | |||
Note that the above specifically excludes taking large, disruptive changes during the 3.1 cycle. | |||
More planning for 3.1 will be forthcoming in the next few days. | |||
== Post-3.1 == | |||
At the same time as we're working on 3.1, we should also be working on mapping out our post-3.1 changes. We've got a couple of thoughts on approaches to mapping out both feature and technology changes that I describe briefly on the [[User:Dmose/Tb Post-3.1 Scratchpad|Tb Post-3.1 Scratchpad]]. After we get the stuff on this page somewhat solidified and rolling, we can dig into that in more detail. | |||