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

[Simon Schampijer]

On 08/02/2009 12:44 PM, Tomeu Vizoso wrote:
> On Sun, Aug 2, 2009 at 04:38, Aleksey Lim<alsroot at member.fsf.org>  wrote:
>> On Sat, Aug 01, 2009 at 05:48:57PM +0200, Tomeu Vizoso wrote:
>>> On Sat, Aug 1, 2009 at 16:48, Aleksey Lim<alsroot at member.fsf.org>  wrote:
>>>> On Sat, Aug 01, 2009 at 04:37:24PM +0200, Tomeu Vizoso wrote:
>>>>> On Sat, Aug 1, 2009 at 16:33, Aleksey Lim<alsroot at member.fsf.org>  wrote:
>>>>>> On Sat, Aug 01, 2009 at 03:19:46PM +0100, Gary C Martin wrote:
>>>>>>> Good luck!
>>>>>>>
>>>>>>> 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.
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> Regards,
>>>
>>> Tomeu
>> Well, absolutely agree..
>>
>> I just mean that this the question is about balance i.e. having thin
>> level(which supported by not activity author) of components that hide
>> differences between several sugars(not all sugar, I think about at least
>> 2 stable release cycles) could let activity developers way to write code
>> for several sugars w/o dipping themselves to compatibility stuff.
>
> Yes, I totally agree it's not a black or white issue, and if we can
> mitigate the downsides, the better we'll strike the balance.
>
> That said, I'm not convinced about duplicating the new API in each new
> activity version so it can also run on older versions. We aren't going
> to break API if we can avoid it, so if for an activity author it's
> very important that new activity versions run on older Sugar versions,
> perhaps that person should stay with the older API for some time
> longer.

Or could release two versions and upload them on ASLO. Of course this is 
not something you do for several releases, but might work for the 
'change period'.

> Imagine if we take the new toolbar stuff and drop a copy in each
> activity bundle. Who is going to take the time to check it works well
> in 0.82-0.86? By works well I mean exercising the activity's
> functionality, not just see it starts up. And when users start filing
> bugs, who is going to check in the older versions, debug and ship a
> fix? And who will check that this fix isn't breaking the activity in
> the other Sugar versions?
>
> Apart from that, if users of 0.82 in Uruguay install the activities
> with the new toolbars, the documentation that they have developed and
> printed won't apply any more to their UI.

Hah, another good point. This is as well why updating is something that 
does not happen that often in reality.

> The release cycle is painful for contributors because in some way
> reduces the number of people that will benefit from their work, as
> opposed to be able to just push new bits every time those get coded.
> But we should remember that our users don't want just new features,
> they also want that their software is localized, has as few bugs as
> possible, is documented (again in their language), integrates with the
> rest of their hardware and software stack, and support is available.
>
> In order to also fulfil those needs, projects decide to release
> software at fixed times instead of continuously. And those involved in
> developing new features are asked to have more patience and understand
> the full complexity of getting new, quality software to the final
> users.
>
> Regards,
>
> Tomeu

Having the coders hat on, Sugar is one of the projects that has a lot of 
users. Personally, I don't feel that I would not reach enough users when 
adding an activity feature that is only available in 0.86

Regards,
    Simon