[Sugar-devel] 0.84 maintenance
tomeu at sugarlabs.org
Sun Dec 6 16:19:50 EST 2009
2009/12/1 Daniel Drake <dsd at laptop.org>:
> Earlier this year, OLPC began developing a new laptop (XO-1.5) and OLPC
> OS (based on Fedora 11). Sugar-0.84 was hot off the presses at that time
> so even though it may feel a little dated today, it's what we've been
> working with and will soon be shipping in large quantity.
> One issue that we've been facing is various regressions since Sugar
> 0.82, some of which have been fixed in Sugar versions later than 0.84
> and some which are still pending. As nobody seems to look after 0.84 any
> more we've been backporting these fixes into a local branch for our OS
> Now we're going to move to making these changes in the usual sugarlabs
> git repositories (sucrose-0.84 branches) and publishing them as regular
> Sugar releases of the main components. This is an improvement/cleanup to
> our current development processes and will open it up for other people
> to become involved. (we already have our 'offline fork' including about
> 15 patches, but we're not being very organised with our development
> working this way)
> So, OLPC will take over maintenance. To start with we'll just be working
> with sugar and sugar-toolkit.
> Me and Sayamindu will be taking care of this. There may be exceptions,
> but in general we'll only be taking patches that are already in master.
> We'll focus on fixes, but if there are really important features
> then we'll take them too (ad-hoc networking support is the 1 example we
> have right now).
> Of course, we'd love support from those of you who are actively involved
> in Sugar development. In a way it's a bit sad for us to see that 0.84
> maintenance already seems to have been halted, but at the same time it's
> certainly our responsibility to make contributions as well.
Thanks a lot for stepping up and taking these tasks, in my view this
is a big step forward for Sugar.
About the general issue of maintenance of stable releases, I don't
think it has to be so black and white. There's lots of ways to
contribute resources that end up benefiting maintenance of stable
- take maintenance of whole modules,
- become comaintainers of whole modules,
- take roles in the community that right now are overloaded on
existing maintainers: coordinator of teams such as development, QA,
- help with bug triaging,
- answering questions in the mailing lists and irc channels,
- help with macro-features such as accessibility support, performance,
static bindings, etc (deployments might not care right now, but these
are areas that Sugar must tackle at some point in order to keep
- keep pinging and summarizing the most important points for deployments,
- and finally, taking maintenance of a stable branch in a module.
I'm not saying the option you have chosen is not the best one in this
circumstances, I just wanted to point out that if more resources are
needed in stable branches, there are still all those ways to keep
improving on this.
> So we'll try and keep the community updated on the issues that we are
> facing, and hopefully you will be interested in helping us out. We'll be
> shipping this to a lot of children. Thanks for the continued
> developments on sugar, but don't forget that
> developing is only a small part of the challenge...!
Yes, thanks for keeping reminding us, for SLs to be a cohesive and
inclusive community, we need a bigger exchange of needs and points of
> Also on this topic - we will certainly run into issues where activities
> themselves progress beyond the Sugar-0.84 platform; if activity authors
> could work to minimize these cases (i.e. keep backwards compatibility,
> remain responsive to bugs) it would help us avoid a huge headache, and
> will help your activities spread to various corners of the globe.
I think this is a current policy of the activity team?
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
More information about the Sugar-devel