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<alsr...@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<alsr...@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 _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel