8.2.1

8.2.1 Planning and process page - Take 2 Gregorio 19:29, 6 October 2008 (UTC)

Objective

Ensure smooth deployment for countries rolling out or upgrading between December and April.

The date and target bug fix set will be determined by the lead customers. The next steps are to listen to the customers and the bug fixes they need. Then can scope the fixes and pick a target release date.

Date

Must be posted by November 15. Any later and Rwanda will miss their opportunity to upgrade.
(We need to check if this is still the case and monitor how their deployment is going. We can have a similar problem as we have with Peru and Ethiopia... that we don't meet their timeline because either it moves or we don't have a good understanding of it. Kimquirk 12:11, 3 October 2008 (UTC))

Change control must start by October 30.
(If we decide Nov 15th is an important date, then change control needs to start by Oct 24. And we should have a candidate release, and a signed build for testing by Oct 31. With this very short time frame, we need to think of this release as a 3 week bug fix sprint starting next week. Kimquirk 12:11, 3 October 2008 (UTC))

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.

- Cambodia
New keyboard support; language support

- 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.
(We have been promising customers this feature for next year, 2009. As we are starting implementation, it might be important to get some pieces of the feature in for early testing, but it is not a goal to get a lease management system in place for 8.2.1. Kimquirk 12:06, 3 October 2008 (UTC))

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:

• Has objective::Enable deployments

Lead customer: Lead customer:: Rwanda
(I think the lead customer might be Peru, who definitely wants to be able to upgrade in Dec/Jan, and they will have over 150k laptops. Kimquirk 12:06, 3 October 2008 (UTC))

Build number and URL: [[Build number::nnn]

Schedule: target date::2008-11-15