canmove, Confirmed users
1,635
edits
Releases/Firefox 9/Ship options: Difference between revisions
Jump to navigation
Jump to search
Releases/Firefox 9/Ship options (view source)
Revision as of 18:01, 25 November 2011
, 25 November 2011no edit summary
No edit summary |
|||
| Line 79: | Line 79: | ||
== Option 5 - "Delay the entire release train" == | |||
* '''Details''' | |||
** Delay the entire release train by a couple of weeks by a couple of weeks | |||
* '''Official Ship''' | |||
*** Early January (3rd or 10th) | |||
* '''Benefits''' | |||
* All the benefits of option 3 AND: | |||
** We set a precedent | |||
*** If a 6-week rapid release point falls within x distance of Christmas, then we'll shift it | |||
*** In future years, we can plan this up front (e.g. if we don't change anything, then next years release & merge would be 1st January - I don't see that happening either). | |||
** Developers still get 6 weeks to land things in the normal cycle - (assuming they are actually on holiday for the Christmas period!) | |||
*** i.e. the cycle after 20th Dec, we're going to loose about 1.5 weeks of dev time due to the holiday period. I don't know quite how much that will equate to, but I could see less being in the next release. There may be a little bit more get in, but I don't think that matters | |||
** If we've delayed the rapid release cycle, if we need a 9.0.1, then we're not going to be up against 10.0 and update fatigue | |||
*'''Downsides''' | |||
** We will still look like we are slipping and/or it'll look like we're not keeping to the original premise of the train runs on time | |||
** If we say we're doing this regularly due to avoiding releases around the holidays, that's just common-sense, isn't it? | |||
** Less predictability of release & merge dates around year end | |||
*** However, we could mitigate this by looking at the dates for the next two or three years now, and publishing a calendar. If we've a consistent rule, then it makes it easier. | |||