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

[Aleksey Lim]

On Thu, Dec 17, 2009 at 01:45:03PM +0000, Aleksey Lim wrote:
> 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).

e.g. almost every GNU/Linux distribution has 3rd-party repositories
but wel lack such infrastructure method in sugar, with Services will have such
3rd party repositories.

> 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

-- 
Aleksey