Confirmed users
2,615
edits
User:Dmose/Tb Roadmap Scratchpad: Difference between revisions
User:Dmose/Tb Roadmap Scratchpad (view source)
Revision as of 00:15, 14 November 2009
, 14 November 2009no edit summary
No edit summary |
No edit summary |
||
| Line 12: | Line 12: | ||
* 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 old-branch maintenance work | |||
* users get benefits of new features sooner | |||
A proposal: | A proposal: | ||
* Shoot for one major release every 4-6 months, | * Shoot for one major release every 4-6 months, based on the closest appropriate [[Firefox/Roadmap]] release. | ||
* Shoot for | * 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. | ||
| Line 25: | Line 27: | ||
(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). | (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. | 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. | ||
| Line 40: | Line 42: | ||
* l10n | * l10n | ||
such that things happen appropriately sized chunks at the right time. It feels like we're likely to want an extension process that's somewhat more lightweight | such that things happen 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. | ||