On Tue, Jul 28, 2009 at 09:00:49AM +0000, Aleksey Lim wrote: > On Tue, Jul 28, 2009 at 01:49:15PM +0545, Daniel Drake wrote: > > 2009/7/28 Aleksey Lim <alsr...@member.fsf.org>: > > > Proposal is not about storing all versions but about possibility of > > > storing not only one(last?) version and we can uninstall old versions > > > by removing entries from journal. > > > > The journal can't delete activities that are installed by a package at > > /usr/share/activities, and I also think it is unlikely that our users > > would realise to do this even if it were possible. > > > > > There is no confusion, sugar is aware of what versions of particular > > > activity it has by using datastore.find() method, so user can run > > > `rpm update`, install any version by downloading .xo and sugar will run > > > last version(when user create new activity instance) or run particular > > > version(if activity object requires it). > > > > I was referring to confusion by deployments and those who are > > diagnosing bugs and soforth. > > > > > btw, activity can declare, in activity instance object, what activity > > > version(range) should be used with this particular instance object. > > > > Sounds like overcomplication. > > > > > > In response to your question on how I think it should be done, I feel > > that it's time to admit that packaging activities in this way is a > > mess. We should leave packaging and the related complications to the > > experts - packagers, and the package manager, and then we can stop > > wasting our time on it. For some kind of cross-distro package manager > > compatibility, someone recently raised the idea of PackageKit which > > seems well worth investigating and given its rapid development can > > probably be adapted to our needs. > > > > IOW I feel that the concept of sugar providing prepackaged binary > > activities should die. > > +1, the way which was chosen by soas is a good example(all activities > come from .xo bundles) > > > I think you would be a good person to work on > > this, and it is an interesting problem. > > > > > Well we can't say to activity developers that they must write > > > backwards-incompatible activities otherwise we won't host them on ASLO. > > > In that case using compatibility ranges of versions could fix problem > > > (w/o obliging developers write complicated code for > > > merge/support-backwards-incompatibility). > > > > It's nice to have the freedom to post whatever I want on ASLO and I'm > > not saying that should change. I'm free to write a buggy activity or > > one that isn't sugarized and post it on ASLO. Even though my activity > > is low quality and doesn't fit into the desktop, I'm welcome to post > > it. The consequence is that my activity probably won't be included in > > deployments, and I'll get some mails from testers making suggestions > > how I could improve it, and maybe even some patches. I'd say that this > > case is no different. > > > > > I like this idea only if all sugar users have 100% access to internet. > > > And they can run "upgrade my 0.82 to 0.84 from internet" process by one > > > click. But imho thats impossible in case of educational infrastructure > > > around of the world. > > > > The responsibility of keeping all machines in sync can be handled by > > the deployments, with the aid of good tools from Sugar/distro/OLPC. > > This is how it already works in the field. It's not your problem, but > > you could certainly help improve those tools and their concepts which > > seem a bit neglected right now. > > Well, for me "0.82 doesn't work with 0.84" is very strong requirement > btw it relates to [2] > > > > imho activities are the same kind of objects - user should have chance > > > to edit/hack/share them like other sugar objects. > > > > Good point, but this seems to be beyond what sugar is capable of at > > the moment and raises more questions. Perhaps once there is the > > ability to modify your activity within sugar, the development activity > > could offer functionality to package up the modified version and save > > it in the journal. Exactly how the user could modify activities, how > > the user-modified activity would be saved on-disk alongside the > > original one, how they would be differentiated in the UI and how the > > user could switch between the two seems to be out of scope of this > > discussion -- or at least I can't see how it would be covered by your > > proposal. > > Yeah it raise many new questions. > > In my mind we can do the first step on this road by creating > activity-less Composite Journal entries[2](objects w/o activity DS > field), so over activities(like Develop) can change activity's code > inplace. And delegate(for the first time at least) all maintenance > procedures (like what version I can change, what version is my backup > copy) to users, they can do this if all activities will be Journal > entries. > > [1] http://wiki.sugarlabs.org/go/Features/Decoupling_of_Sucrose > [2] http://wiki.sugarlabs.org/go/Features/Object_Bundles#METADATA_file
Anyway [1] proposal doesn't do any non-obvious or complicated stuff, just the other way: * it simplifies activity registry related code(less code, less bugs) since all job does OB[3] and shell just need to track DS * from users POV, it adds only one(but obvious) thing - if user deletes Journal entry which named "Terminal-25" he loses version 25 of Terminal activity, and if he has "Terminal-24" Journal entry, next time when after click on that entry(or entry in Home view) Terminal-24 will start [3] http://wiki.sugarlabs.org/go/Features/Object_Bundles -- Aleksey _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
