[Sugar-devel] Maintaining activities for older releases (was Re: Initial implementation of toolbars design)

[Simon Schampijer]

On 08/01/2009 05:48 PM, Tomeu Vizoso wrote:
[...]
>>>>> Quick question: Are you going to try and support existing
>>>>> deployments and keep and maintain both toolbar implementations? That
>>>>> is certainly (but painfully) my plan, as that's where 99.9% of our
>>>>> users are. You might need to wish me luck as well, as I'm not half
>>>>> as code prolific as you ;-)
>>>> I have secret weapon, sugar-port[1] for that purpose :)
>>> You mean each of those activities will ship with its own copy of the
>>> new toolbars? That's quite a bit scary from the support POV.
>> Well, not so much as you can think..
>> API for new toolbars won't be changed(I hope), so I need only `cp`
>> proper sources from master repo(if it will contain fixed code)
>> anyway I don't see another way except not using new toolbars at all.
>> I'm personally dislike idea of having several branches in that
>> particular case where there is no changes in activity code but only
>> changes in 3rd party components.
>
> What is usually done in FOSS projects is to keep adding features in
> each new release, but only backport bugfixes to past releases, and
> that only if there's enough resources and interest.

Right. That sounds like a sane thing to do, to keep the project moving.

> This is because all projects have limited resources but also have
> plans to move forward and expand the work done in every release.
>
> If we tell our users that new versions of activities are going to run
> on all versions of Sugar, this means that with every release we are
> going to have less resources to work on new releases because the
> number of platforms we need to support keep growing. We would be
> putting a hard limit on Sugar's growth.
>
> Given that right now we aren't able to properly maintain a single
> release, I see as very bold trying maintain all past releases and at
> the same time doing excellent new releases.
>
> To be clear, I'm not saying that we should drop support for our
> current users. Rather that if we want to scale, live up to
> expectations and give a good experience to users of past releases
> (most users) then we should figure out how our resources can grow at
> least as fast as our needs.

Glad, that Sugar has users. And users means pressure. One can not change 
things quickly, once one have users. The toolbar redesign has been 
pending for quite a while now - at one point we have to make a cut.

The problem I see here - are dependencies: activities do not have hard 
dependencies. I guess it is 'solved' by the fields in ASLO. And the 
updater can manage those, I guess.

> One common way is to let downstreams support their own users. It's
> very cool that Uruguay wants their kids to use Sugar, and obviously
> the Sugar Labs community will be thrilled to be able to contribute so
> children there have access to better learning. But we'll be doing them
> a disservice if we let their government believe that a bunch of
> hippies around the world is going to support the software they use in
> the field, the newer software releases, and also the releases that
> other countries have decided to use.

Very good point! Deployments need to take action as well. If you have 
non open source software you pay for the support. In open source world, 
you organize yourself, or invest in people doing it for you. The issue 
is that in many cases, the open source model is just seen as a way to 
cut down costs. That is why I am not happy about terms like it 'does not 
cost something' - at least if the philosophy is not explained at the 
same time.

> How I would expect this to work is that if Uruguay is using 0.82 and
> wants a feature or bugfix that appeared in 0.86, then they would put
> the resources needed to make a new release for 0.82. They don't need
> to do it alone, they can do it as part of their involvement in Sugar
> Labs and can pool resources with other deployers of 0.82, but the key
> point is that it's not expected that a super-volunteer is going to
> keep sync'ed all activities for all versions.

+1

> Apart from the practical issue of scalability, we should also remember
> that our mission is to improve the learning of _all_ children of the
> world, not just the ones currently using Sugar.

Yes, we are the upstream project, and we need to keep the boat moving. 
If we are too much involved with what happens downstream we won't move fast.

Thanks for this summary,
    Simon