User:Dmose/Tb Roadmap 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.

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 them with feedback from the community.

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, there are some process changes I'd like to propose to help us get there.

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).
• Make 3.next a short-cycle release based on 1.9.2 or (opportunistically) 1.9.3. It would be strongly focused on low-hanging fruit rather than large features.

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 are may sometimes be hard or impossible to segment into 4-6 month chunks
• We could end up having to backport some patches to more than one old branch, as Firefox and Gecko developers are doing today.
• We're going to have to get significantly better at avoiding last-minute localization issues.

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

Feature & Component Roadmaps

Rather than having a single big roadmap that then ends up having lots of things cut from it at the end, davida has suggested that we instead have individual roadmaps for different feature and code areas, particularly those where we can avoid a lot of cross-dependencies. We can then pick appropriate pieces of work from various different road maps and target them at a given release, and if some don't make the release they're originally slotted for, it doesn't disrupt the overall roadmap for that release.

Clearly, the devil here is going to be in the details, so the next thing on my to-do list is to come up with a few such straw-man roadmaps, probably in concert with clarkbw and davida, so that we can get a feel for how they will and won't work.

UI Iteration Via Extension

We did some UI iteration in extensions in Thunderbird 3, with varying degrees of pain-upon-landing. The big win, it felt like, was the ability to get UI to a workable and understood state before imposing it on everyone using nightly builds. We'd like to explore this methodology more going forward, but we'll need to nail down more details about our process and what sorts of experiments with it that we'd like to do. In particular, we'll need to think about how we handle:

• UI-review
• code-review
• test writing
• l10n

such that things happen in appropriately sized chunks at the right time. It feels like we're likely to want an extension process that's somewhat more lightweight than in our in-tree process. My current thinking is to prioritize the product/feature definition stuff above sorting out these processes, and do more thinking here once we're ready to start poking at individual extensions. That said, if someone else is interested in picking this stuff up sooner, come talk to me.