Confirmed users
685
edits
Websites/Mozilla.org/Roadmap 2011: Difference between revisions
Websites/Mozilla.org/Roadmap 2011 (view source)
Revision as of 18:29, 3 February 2011
, 3 February 2011→Open Questions
m (→Open Questions) |
|||
| Line 61: | Line 61: | ||
* [[Mozilla.org/Roadmap_2011/Q2|Q2]] | * [[Mozilla.org/Roadmap_2011/Q2|Q2]] | ||
= Open Questions = | = Open Questions<br> = | ||
#Implementing big improvements with as little transition needed as possible (Improvements to SVN workflow & git on the server end, git-svn for pulling in localizers) (James)<br> | |||
#Implementing big improvements with as little transition needed as possible (Improvements to SVN workflow & git on the server end, git-svn for pulling in localizers) (James)<br> | |||
#The future of Kubla (James)<br> | #The future of Kubla (James)<br> | ||
#How and when can we enhance our SVN setup to code freeze and release code? (James)<br> | |||
#How and when can we enhance our SVN setup to code freeze and release code? (James)<br> | #Discussing what state trunk is in -- is trunk authoritative? can we clobber production and stage and recreate these branches from current trunk to reestablish a fork revision? (Morgamic)<br> | ||
#Discussing what state trunk is in -- is trunk authoritative? can we clobber production and stage and recreate these branches from current trunk to reestablish a fork revision? | |||
<br> | <br> | ||
Answered Questions<br> | Answered Questions<br> | ||
1. How do we best handle "one-offs" - defined as changes tied to a moving date that falls between our scheduled releases? These will be fairly common; I'd estimate there will be 2 small "one-offs" every cycle. | 1. How do we best handle "one-offs" - defined as changes tied to a moving date that falls between our scheduled releases? These will be fairly common; I'd estimate there will be 2 small "one-offs" every cycle. | ||
| Line 88: | Line 84: | ||
c) Budget for these so they stop feeling like favors. These are constant changes that happen when software schedules are unpredictable (even though we'll get better). Perhaps we reduce the amount of bugs in each sprint in order to budget for two "one-offs" each cycle? <br> | c) Budget for these so they stop feeling like favors. These are constant changes that happen when software schedules are unpredictable (even though we'll get better). Perhaps we reduce the amount of bugs in each sprint in order to budget for two "one-offs" each cycle? <br> | ||
'''-A: We'll need to stay fairly flexible, but also work with Engagement/PMM to plan changes farther ahead of time. '''<br> | '''-A: We'll need to stay fairly flexible, but also work with Engagement/PMM to plan changes farther ahead of time. '''<br> | ||
2. Should we change the weekly triage meeting to a day that won't fall on a code freeze or release? (Mon, Wed, Fri) '''- A: Yes, changed to Mondays'''<br> | 2. Should we change the weekly triage meeting to a day that won't fall on a code freeze or release? (Mon, Wed, Fri) '''- A: Yes, changed to Mondays'''<br> | ||
<br> | <br> | ||