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

[Aleksey Lim]

On Sun, Aug 02, 2009 at 02:38:48AM +0000, Aleksey Lim 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

Just to make this discussion clear to myself..

This discussion is all about having two POVs, one from
core-teams/distributions then people create/distribute the "product"
(GNOME, glucose, etc.). The second one comes from
activity-developers/3rd-party-developers/doers/occasional-doers, they
should have a chance(optional) for more flexible behaviour.

These two POVs don't exclude each others.

For example, I'm not going to switch from "product" scheme for GNU/Linux
distribution I'm using(well, since I'm using Gentoo I've already did it
in some sense:) and so for sugar core which has predictable release
schedule.

But the second POV is all about decentralization of
development-process/responsibilities i.e. having all
dependencies/features that could be useful for activity developers/doers
based on core/distributions schedules is nonsense, all dependencies,
including not only system ones like glibc/gtk/etc but
sugargame(olpcgame)/groupthinking/my-super-puper-widget. We can decouple
these dependencies/features to system(based on global schedules like
GNOME's sugar's) and users(still based on schedules that users' ones).

Thus second POV doesn't exclude first one but benefit from its existence
(my super-puper-widget relies on pygtk release schedule). So, that
doesn't mean that people of 1st POV are not so smart but means that they
do a bit different job(but unique job which let 2nd POV exist).

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

-- 
Aleksey