User:Dmose/Tb Roadmap Scratchpad

From MozillaWiki
< User:Dmose
Revision as of 03:20, 13 November 2009 by Dmose (talk | contribs) (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…')
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search
Draft-template-image.png THIS PAGE IS A WORKING DRAFT Pencil-emoji U270F-gray.png
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 reasons for this 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

A proposal:

  • Shoot for one major release every 4-6 months, from the nearest aligned Firefox/Roadmap release.
  • Shoot for an alpha or beta 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.

Process Changes

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 should include tests.