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

[Tomeu Vizoso]

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:
>> >> On 1 Aug 2009, at 14:51, Aleksey Lim wrote:
>> >>
>> >> >On Sat, Aug 01, 2009 at 02:12:50PM +0100, Gary C Martin wrote:
>> >> >>On 31 Jul 2009, at 10:54, Simon Schampijer wrote:
>> >> >>
>> >> >>>>1). I was hoping for more feedback before we lock things down,
>> >> >>>>but it's
>> >> >>>>been pretty quiet. I was hoping to hack TurtleArt with a temporary
>> >> >>>>toolbar imitation and get some real usability input from kids,
>> >> >>>>but not
>> >> >>>>sure we have the time?
>> >> >>>
>> >> >>>We land it today, Browse and Write are ready, so we can get
>> >> >>>feedback on them. From the schedule we still have a bit of time.
>> >> >>>So I am positive.
>> >> >>>
>> >> >>>>2). Is it possible to have the "title entry" input field default
>> >> >>>>width
>> >> >>>>set to allow for 9 icons on the right (this is the maximum
>> >> >>>>needed for
>> >> >>>>current Activity designs), then allow it scale down to some min
>> >> >>>>width if
>> >> >>>>extra icons are added? I would rather there was a little
>> >> >>>>flexibility in
>> >> >>>>the "title entry" rather than have the "Stop" and "Keep" buttons
>> >> >>>>be the
>> >> >>>>first to disappear.
>> >> >>>
>> >> >>>Looks like we are over this point, following the other discussions
>> >> >>>in this thread.
>> >> >>>
>> >> >>>>3). FWIW, I'm considering the "share with" icon should really be
>> >> >>>>over on
>> >> >>>>the right (if sharing feature are present). So the far right
>> >> >>>>icon order
>> >> >>>>would be "share with", "keep version", "stop".
>> >> >>>
>> >> >>>Same here.
>> >> >>>
>> >> >>>Btw - we went at the moment for eben's design. Gary, we could use
>> >> >>>your design (with title entry in the top) and test it out, if you
>> >> >>>think it is worth doing comparing tests.
>> >> >>
>> >> >>Let's get feedback with what has been implemented so far and iterate
>> >> >>on it if there are agreed issues. My main concern at the moment is
>> >> >>that we have complicated the trivial Activity case, in that there is
>> >> >>no longer an option for just providing a single main toolbar. Every
>> >> >>Activity has to now deal with loss of canvas space and dynamic
>> >> >>resizing caused by the secondary activity toolbar design (that's one
>> >> >>reason I didn't like that path).
>> >> >>
>> >> >>Who is the poor soul that's going to have to sort out TamTamMini, I
>> >> >>vote for alsroot ;-b
>> >> >
>> >> >Well, I have around 14(including TamTamMini) activities on git.sl.o
>> >> >to switch to new toolbars.. so you can wish me luck.
>> >>
>> >> 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

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