On Sun, 2008-06-22 at 15:02 -0400, Kim Quirk wrote: > 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.
This is going to be were an interesting intersection between community and corporate occurs. Kernel.org releases every couple of months and Distributors like RedHat end up supporting a given release for several years. > 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. Two releases per year make sense. Particularly when add in the fact that we have two hemispheres with opposing springs and falls. > 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. At least for now 6 moths releases with 12 month support seem pretty sane. One more thing to think about is making Sugar releases one month and distributions releasing one month later. Releasing like this should allow distributions, currently OLPC, to plan on constant Sugar releases dates. At the same time, the cost and effort of developing Sugar is spread across a broader audience. > 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. One way of handling the 'stale' issue is to detach activity releases from OS releases. I currently am working on modifying addons.mozilla.org to serve activities for activities.sugarlabs.org. > 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. Here, we need to make a very conscious effort of creating support to be collaborative. It is very frustrating to every single distribution trying to maintain individual patch sets for their support releases. >From a marketing point of view, product differentiation can be useful but from a software development point of view collaboration is critical. Dfarning _______________________________________________ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
