Confirmed users
2,615
edits
User:Dmose/Tb Roadmap Scratchpad: Difference between revisions
User:Dmose/Tb Roadmap Scratchpad (view source)
Revision as of 01:37, 24 November 2009
, 24 November 2009→Dev Cycle
No edit summary |
|||
| (3 intermediate revisions by the same user not shown) | |||
| Line 7: | Line 7: | ||
== Dev Cycle == | == Dev Cycle == | ||
Rather than having super long releases, we'd like to release significantly more frequently than we have historically done. Key | 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 | * 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 | * 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 | * pressure to land features before they're ready is reduced, because the next shipping train isn't so far in the future | ||
* less | * less maintenance work on extremely old branches | ||
* users get benefits of new features sooner | * users get benefits of new features sooner | ||
| Line 20: | Line 20: | ||
* 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). | ||
* 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. | * 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 == | == Testing == | ||