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  > > 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(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.  http://wiki.sugarlabs.org/go/Features/Decoupling_of_Sucrose  http://wiki.sugarlabs.org/go/Features/Object_Bundles#METADATA_file > Daniel > -- Aleksey _______________________________________________ Sugar-devel mailing list Sugarfirstname.lastname@example.org http://lists.sugarlabs.org/listinfo/sugar-devel