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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> > _______________________________________________ Sugar mailing list [email protected] http://lists.laptop.org/listinfo/sugar
