On 08/02/2009 12:44 PM, Tomeu Vizoso wrote: > On Sun, Aug 2, 2009 at 04:38, Aleksey Lim<alsr...@member.fsf.org> 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 >> 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. > > Yes, I totally agree it's not a black or white issue, and if we can > mitigate the downsides, the better we'll strike the balance. > > That said, I'm not convinced about duplicating the new API in each new > activity version so it can also run on older versions. We aren't going > to break API if we can avoid it, so if for an activity author it's > very important that new activity versions run on older Sugar versions, > perhaps that person should stay with the older API for some time > longer.
Or could release two versions and upload them on ASLO. Of course this is not something you do for several releases, but might work for the 'change period'. > Imagine if we take the new toolbar stuff and drop a copy in each > activity bundle. Who is going to take the time to check it works well > in 0.82-0.86? By works well I mean exercising the activity's > functionality, not just see it starts up. And when users start filing > bugs, who is going to check in the older versions, debug and ship a > fix? And who will check that this fix isn't breaking the activity in > the other Sugar versions? > > Apart from that, if users of 0.82 in Uruguay install the activities > with the new toolbars, the documentation that they have developed and > printed won't apply any more to their UI. Hah, another good point. This is as well why updating is something that does not happen that often in reality. > The release cycle is painful for contributors because in some way > reduces the number of people that will benefit from their work, as > opposed to be able to just push new bits every time those get coded. > But we should remember that our users don't want just new features, > they also want that their software is localized, has as few bugs as > possible, is documented (again in their language), integrates with the > rest of their hardware and software stack, and support is available. > > In order to also fulfil those needs, projects decide to release > software at fixed times instead of continuously. And those involved in > developing new features are asked to have more patience and understand > the full complexity of getting new, quality software to the final > users. > > Regards, > > Tomeu Having the coders hat on, Sugar is one of the projects that has a lot of users. Personally, I don't feel that I would not reach enough users when adding an activity feature that is only available in 0.86 Regards, Simon _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel