User:Dmose/Tb Post-3.0 Scratchpad

	THIS PAGE IS A WORKING DRAFT
	The page may be difficult to navigate, and some information on its subject might be incomplete and/or evolving rapidly. If you have any questions or ideas, please add them as a new topic on the discussion page.

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.

Dev Cycle

Rather than having super long releases, we'd like to release significantly more frequently than we have historically done. Key advantages include:

• keeping in closer sync with Firefox, so that we get the benefit of both the latest features and security fixes
• shorter plans tend to be more accurate than longer ones
• pressure to land features before they're ready is reduced, because the next shipping train isn't so far in the future
• less maintenance work on extremely old branches
• users get benefits of new features sooner

A proposal:

• 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).

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
• Sufficiently large features may sometimes be hard or impossible to segment into 4-6 month chunks
• 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.

Testing

To increase quality, and to improve our ability to make non-trivial changes to the codebase without regressing functionality, I'd like to bring our code review policies in line with those of browser and toolkit: all patches to directory, editor, mail, and mailnews should include tests unless there's a specific reason why that's impractical or not sensible.

(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 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.