[Sugar-devel] 0.84 maintenance

[Tomeu Vizoso]

2009/12/1 Daniel Drake <dsd at laptop.org>:
> Hi,
>
> 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
> builds.
>
> 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
releases:

- 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,
community, etc.

- 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
growing),

- 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
view.

> 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?

Thanks,

Tomeu

-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning