Making updating easier and Planning for Support

[Kim Quirk]

Deepak (and others interested in support),

This is a good question and we've talked about it from time to time.

The OLPC Support planning is really just now underway. We've made some
good progress on the Hardware side of support (spare parts, repair
centers, warranty, etc); and now we need some focus on the Software
side of Support.

Here is my proposal:
First I'd like to begin separating 'Sustaining Engineering' functions
from 'Development Engineering'. Sustaining is focused on the problems
and bug fixes needed for countries (and G1G1). There has to be a close
tie in between the groups and training from development to sustaining,
but it should allow the Development team to be more forward looking.

Secondly, I am proposing that our Support team can only support one
major release along with the current one. With school systems being
run on yearly basis, this would suggest that we plan for 2 major
releases per year. That would give schools a chance to use either the
fall or spring release as their base; and then plan to upgrade between
school years to the next release.

Here is an example:
We provide release 8.2.0 in Aug/Sept;  school systems that start in
Feb or March would be encouraged to use this release, add their
content and activities, test, and get the release out to the XOs
before the start of the school year. We might need to provide 8.2.1 or
8.2.2 as they do their testing as major issues are found.

We would plan 9.1.0 for the March time frame, which gives school
systems that start in Aug/Sept a chance to test this release through
the summer; and help us find bugs that might require 9.1.1.

Then we would continue to provide patches and support for 8.2 until
the follow Aug/Sept, when 9.2.0 is getting ready for release; and we
would provide patches and support for 9.1 until the following March,
when 10.1.0 is getting ready for release.

We had been talking about as many as 3 or 4 major releases per year...
so this is a good point of discussion and something I'd like to
finalize in the next few weeks.  Perhaps the minor/patch releases can
allow small features so developers don't feel like they have only two
times/year to get in a new feature. We have to think about what that
means for testing and support. We also have to keep in mind that our
audience is schools, teachers and students, not developers.

If we start with a set of goals for the Support of our SW, then we can
have a good discussion on this. Here are the three goals I have so
far:
1 - Ensure that security issues and major bugs are addressed in a timely fashion
2 - Ensure that there are resources available to review, recreate, and
help fix and test serious and critical problems from the field.
3 - Manage the process of development, test, and release for
minor/patch releases.

The resources we need for 'support' are almost the same as for working
on the next major release:  sustaining eng, development, build,
release and test resources. So we really have to limit what we can
support to one release back -- which has an impact on how many major
releases we should do each year.

Kim



On Sat, Jun 21, 2008 at 7:37 PM, Deepak Saxena <dsaxena at laptop.org> wrote:
> On Jun 21 2008, at 20:10, Kim Quirk was caught saying:
>> Sounds great! We've discussed a similar thing here, but I don't
>> believe there has been any time for that.
>>
>> For g1g1 people there could possibly be 2 options - 1. Upgrade from
>> 656 to 8.1.1, with the automatic second step of adding activities; or
>> 2. Cleanstall to the 8.1.1 build that already includes activities (a
>> signed candidate for this is available today).
>
> I've been thikning about update issues a bit and was wondering
> if we have plans/processes in place to handle maintaince of multiple
> releases? Meaning that when we release 8.2, will we still provide bug
> fixes and security updates to 8.1.1 users or are we expecting everyone
> to move forward to 8.2 and just EOL 8.1.x?
>
> Thanks!
> ~Deepak
>
> --
> Deepak Saxena <dsaxena at laptop.org>
>