Confirmed users
2,615
edits
User:Dmose/Tb Roadmap Scratchpad: Difference between revisions
Jump to navigation
Jump to search
User:Dmose/Tb Roadmap Scratchpad (view source)
Revision as of 02:48, 17 November 2009
, 17 November 2009no edit summary
No edit summary |
No edit summary |
||
| 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 | |||
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 with the intent of finding out how it works for us. | |||
== Testing == | == Testing == | ||