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

[Tomeu Vizoso]

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.

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.

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

>> >>
>> >> Regards,
>> >>
>> >> Tomeu
>> >>
>> >> > [1] http://wiki.sugarlabs.org/go/Development_Team/sugar-port
>> >> >
>> >> >>
>> >> >> Regards,
>> >> >> --Gary
>> >> >>
>> >> >
>> >> > --
>> >> > Aleksey
>> >> >
>> >>
>> >
>> > --
>> > Aleksey
>> >
>>
>
> --
> Aleksey
>