Re: [Techteam] Making updating easier and Planning for Support
Hi Kim - On Sun, Jun 22, 2008 at 3:02 PM, Kim Quirk [EMAIL PROTECTED] wrote: 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. Overall, I think your analysis and plan are spot on. In my experience, unfortunately, it seems that educational institutions - specially at the country level - are fairly slow moving. In your plan the expectation is that all the regions in a given hemisphere are in lockstep with us on the yearly upgrade cycle. I suspect that it will be rather hard for them to achieve. Perhaps we just declare them unsupported and move on - I am not sure how this will work. My recommendation is to have _one_ major release per year for countries. Damn slow, I know - We had been talking about as many as 3 or 4 major releases per year... I do think we'll want to have feature releases that build up to the major supported release. Those are for our developers / testers / pilot communities, and they are just not supported long term (not formally at least). 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. The developers and tinkerers audience will bring bug reports and continued development, which leads to stability - so we can keep things going. cheers, m -- [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Techteam] [sugar] Making updating easier and Planning for Support
On Sun, Jun 22, 2008 at 11:29 PM, David Farning [EMAIL PROTECTED] wrote: Two releases per year make sense. Particularly when add in the fact that we have two hemispheres with opposing springs and falls. Only if you assume we can get countries in lockstep with us. Any number of things can distract the local team from making the upgrade, and - wham - they'll be unsupported. When it happens, rather than leaving them in the cold I suspect we'll end up with 3 or 4 versions to support - 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. Sugar and activities can be making releases a lot more often - and I think OLPC should be doing the same. It only makes sense to tag a long-term-support release once you've been making smaller ones. At the end of the day, countries want the whole set (base OS, Sugar, activities) as one package. The don't have the expertise or drive to build their own. cheers, m -- [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Techteam] [sugar] Making updating easier and Planning for Support
On Mon, Jun 23, 2008 at 11:18 AM, David Farning [EMAIL PROTECTED] wrote: As Kim stated earlier, in the end this becomes a cost of effort issue. From a developer point of view the more releases the better. From a support perspective maintaining several long releases can quickly suck the energy from a project. Definitely - what my experience (as dev and release mgr for a few versions of moodle) tells me is that we want to copy how large distros operate, but in a smaller fashion: - Treat our focused dev projects (ie Sugar) as an upstream to the distro. This means that the Sugar team will prob want to make frequent releases, some of them reasonably lined up with the distro's schedules. What you are doing w the activities hosting is great in this regard. - Run milestone integration releases, without a strong promise of support for end users. If we stop doing this, parts might drift, and QA won't have anything to work on. Debian does not do this in an organised fashion (their testing branch is an informal version of this) and that is part of the reason their release cycles are glacial. Ubuntu has 6-monthly releases that are short-term supported - and they have an much easier time in hitting their schedule and delivering a predictable outcome. We don't want to promise the support Ubuntu promises - but cutting integration releases is IMHO quite important. cheers, m -- [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Techteam] [sugar] Making updating easier and Planning for Support
On Mon, 2008-06-23 at 10:36 -0400, Martin Langhoff wrote: On Sun, Jun 22, 2008 at 11:29 PM, David Farning [EMAIL PROTECTED] wrote: Two releases per year make sense. Particularly when add in the fact that we have two hemispheres with opposing springs and falls. Only if you assume we can get countries in lockstep with us. Any number of things can distract the local team from making the upgrade, and - wham - they'll be unsupported. When it happens, rather than leaving them in the cold I suspect we'll end up with 3 or 4 versions to support - 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. Sugar and activities can be making releases a lot more often - and I think OLPC should be doing the same. It only makes sense to tag a long-term-support release once you've been making smaller ones. As Kim stated earlier, in the end this becomes a cost of effort issue. From a developer point of view the more releases the better. From a support perspective maintaining several long releases can quickly suck the energy from a project. Dfarning ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Making updating easier
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? My perception of our basic purpose is that we're in the business of creating reference OSes which can be modified with OLPC support at fixed points of extension (activities, keyboard settings, etc.; Peru) or which can be used for inspiration to create more customized (but less OLPC-supported) works (Uruguay, Nepal). In the latter case, our expectation is that people who customize our examples will periodically meet with us to exchange mergeable material. We also hope that they will, from time to time, rebase their changes onto our newer reference OSes. If one accepts this statement of basic purpose, then it follows for me that our basic responsibility is to create, document, and train people in infrastructure, packaging, build creation, issue/request-tracking, and release processes which facilitate parallel work on each of the streams of development that have active audiences. Recent examples of our response to this proposed responsibility include * the creation of the USB-based fixed-extension customization technology, * Scott's image-builder for producing disk images from customization keys; i.e. for making local releases from reference OSes, * our mutual formulation of -build, -devel, -testing, and -updates Koji tags for the construction and maintenance of the package-sets associated with releases. * the work that went in giving, recording, and publishing Scott's mini-conference our present series of tech talks * time spent working with Emiliano Pastorino of Uruguay on incorporating knowledge and technology from Uruguay's customizations of the 640-656 series builds into our own. However, as you rightly remind us, there is a fundamental question which is not addressed by any of the work described above: what support, if any, does OLPC offer for its reference OS releases? Is the support bounded below by some stronger basic responsibility? Is it bounded above by some limit on the temporal extent of the support? I don't have any idea what the real answers to those questions might be. Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Making updating easier and Planning for Support
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] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Making Updating Easier
2 releases per year is the right way to go. I can't imagine using more than two XO releases per year, barring an important security or bug fix. It is just too time consuming to test out a new release and more importantly, train the teachers about any new features or anomalies. I hope to update our XO OS images for the first time in September. @Michael: I would like to share back any important changes we made to the OS image but the changes I made were quite trivial. Primarily, my changes were customizing the order that the activities were displayed in and the installation of additional rpms. Sulochan is working on a shell script to automatically update activities when there are new versions on the school server. I will ask him to communicate his work back. Keep up the good work Bryan Berry OLE Nepal ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Making updating easier and Planning for Support
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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Making updating easier
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). If we can keep the upgrade or cleaninstall very simple, that would be great! Thanks for any help any can bring to this! Kim On 6/21/08, Christoph Derndorfer [EMAIL PROTECTED] wrote: Hello all, one of the things that repeatedly came up during a greet meetup at Friends Community School near DC which we had earlier today was that updating the software on the XOs was still too painful for many people. So especially with G1G1 2008 looming on the horizon I'm thinking that it might make sense to come up with an easier way to update the software. Some of the potential solutions discussed are * adding a separate activity that basically acts as a simplified gui for olpc-update, allowing users to upgrade to the latest signed software-builds (with an option to include release candidates) * integrating update functionality into the sugar-control-panel * adding a gui for Bert Freudenberg's script What do you guys think? Cheers, Christoph -- Christoph Derndorfer Co-Editor OLPCnews, http://www.olpcnews.com ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Sent from Gmail for mobile | mobile.google.com ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Making updating easier
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] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
