8.2.1: Difference between revisions
(fix typo) |
No edit summary |
||
Line 1: | Line 1: | ||
8.2.1 Planning and process page - Take 1 by [[User:Gregorio|Gregorio]] 21:03, 2 October 2008 (UTC) |
|||
= Objective = |
|||
Improve stability over 8.2.0. 90% or more of the work should be bug fixes. Ensure smooth deployment for countries rolling out or upgrading between December and April. |
|||
= Date = |
|||
Must be posted by November 15. Any later and Rwanda will miss their opportunity to upgrade. |
|||
Change control must start by October 30. |
|||
Final regression test must start by November 7. |
|||
= Target Customers = |
|||
- Peru <br> |
|||
School year starts in March but 9.1 wont be ready. |
|||
- Uruguay ? <br> |
|||
Check when school year starts and what it will take for them to use this release. |
|||
- Rwanda <br> |
|||
School out as of October 31. Will have a window until December to upgrade |
|||
- Haiti <br> |
|||
Deployment time frame on hold but should be ready by 8.2.1 |
|||
- Palestine <br> |
|||
Needs Arabic working |
|||
- G1G1 <br> |
|||
Target factory imaging as of October 1. Target delivery in December. |
|||
- Any other target customers? Afghanistan, Mongolia, others.... <br> |
|||
= Rules of engagement = |
|||
We will collect the list of target bug fixes by reviewing open trac items and setting the ones we want to address to Milestone 8.2.1. |
|||
Priority field will be set to High or Blocker. High bugs will be accepted until a certain date tbd. After that only blockers will be accepted. |
|||
Bug scrub decision criteria: <br> |
|||
If a bug will prevent a target customer from deploying it we will consider a high priority/blocker for the release. <br> |
|||
On G1G1 if a bug will prevent a lot of support calls we will consider it. e.g. WPA improvements may be needed. <br> |
|||
Otherwise we will consider any bugs which have a High Value and Low effort or a High Value and High Effort as long as the ROI is clear and the bug can be addressed in the target time frame. |
|||
= Major Work to Consider = |
|||
We should decide if we want to have any focus on each of these. <br> |
|||
* Power |
|||
Could be a test only effort where QA must write and execute a full set of tests. |
|||
* Collaboration |
|||
Same as power. Don't plan on major re-work but improve test capacity. Additionally consider bug fixes which are well contained? |
|||
* Lease management |
|||
Critical customer issue. Need to decide if its in or out or if there is a minimal implementation we can do. |
|||
== Standard information == |
== Standard information == |
||
(These are all semantic annotations that other pages such as [[Releases]] can query.) |
(These are all semantic annotations that other pages such as [[Releases]] can query.) |
||
Line 8: | Line 65: | ||
Status: [[status::nascent]] |
Status: [[status::nascent]] |
||
Primary maintainer: |
Primary maintainer: [[Primary maintainer::User:CScott]] |
||
ECO: not yet |
ECO: not yet |
Revision as of 21:03, 2 October 2008
8.2.1 Planning and process page - Take 1 by Gregorio 21:03, 2 October 2008 (UTC)
Objective
Improve stability over 8.2.0. 90% or more of the work should be bug fixes. Ensure smooth deployment for countries rolling out or upgrading between December and April.
Date
Must be posted by November 15. Any later and Rwanda will miss their opportunity to upgrade.
Change control must start by October 30.
Final regression test must start by November 7.
Target Customers
- Peru
School year starts in March but 9.1 wont be ready.
- Uruguay ?
Check when school year starts and what it will take for them to use this release.
- Rwanda
School out as of October 31. Will have a window until December to upgrade
- Haiti
Deployment time frame on hold but should be ready by 8.2.1
- Palestine
Needs Arabic working
- G1G1
Target factory imaging as of October 1. Target delivery in December.
- Any other target customers? Afghanistan, Mongolia, others....
Rules of engagement
We will collect the list of target bug fixes by reviewing open trac items and setting the ones we want to address to Milestone 8.2.1.
Priority field will be set to High or Blocker. High bugs will be accepted until a certain date tbd. After that only blockers will be accepted.
Bug scrub decision criteria:
If a bug will prevent a target customer from deploying it we will consider a high priority/blocker for the release.
On G1G1 if a bug will prevent a lot of support calls we will consider it. e.g. WPA improvements may be needed.
Otherwise we will consider any bugs which have a High Value and Low effort or a High Value and High Effort as long as the ROI is clear and the bug can be addressed in the target time frame.
Major Work to Consider
We should decide if we want to have any focus on each of these.
- Power
Could be a test only effort where QA must write and execute a full set of tests.
- Collaboration
Same as power. Don't plan on major re-work but improve test capacity. Additionally consider bug fixes which are well contained?
- Lease management
Critical customer issue. Need to decide if its in or out or if there is a minimal implementation we can do.
Standard information
(These are all semantic annotations that other pages such as Releases can query.)
Release notes: Release notes/8.2.1
Status: status::nascent
Primary maintainer: Primary maintainer::User:CScott
ECO: not yet
Primary objective:
- (add [[Has objective::blah]] when known)
Lead customer: Lead customer:: Uruguay
Build number and URL: Build number::999
Schedule: tbd (add [[target date::2008-xx-xx]] when planned date is known )