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

[Aleksey Lim]

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.

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

-- 
Aleksey