<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=UTF-8" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> Bernie Innocenti wrote: <blockquote cite="mid:1272545166.14634.377.camel@giskard" type="cite"> <pre wrap="">El Sat, 24-04-2010 a las 07:19 +0000, Aleksey Lim escribió: </pre> <blockquote type="cite"> <pre wrap="">In my mind activities on ASLO are not something like packages in regular GNU/Linux distribution. ASLO is not one centralized product, as already was mentioned several times it is (or should) palace to share your work (maybe in trash) with others thus we (will)have bunch of outdated/ forgotten projects. And it is ok for sugar (but not for GNU/Linux distributions). </pre> </blockquote> <pre wrap=""> I also intended ASLO this way, until I realized that builds are being composed by picking the latest versions of activities from ASLO directly. Same goes for the update control panel. Because of this, users expect the things they find on ASLO to actually work and get pissed off if a new version of an activity breaks horribly. </pre> </blockquote> Some random thoughts: 1-) Is there no way to detect the requesting hardware and deployment first and then have ASLO filter the appropriate applications for download? 2-) An INDEXED rpm depository to install from, or Download from would be nice for advanced users. 3-) I have a CD Image of 111 .xo activities for Download from: <a class="moz-txt-link-freetext" href="http://people.sugarlabs.org/Tgillard/ASLO.iso">http://people.sugarlabs.org/Tgillard/ASLO.iso</a> for drag-drop "sneaker-net" installs. Maybe a down-loadable set of these CD Images should be maintained for different deployments and hardware. (this would also save a lot of server usage) <blockquote cite="mid:1272545166.14634.377.camel@giskard" type="cite"> <pre wrap="">Distributors (like Paraguay Educa and OLPC) need to introduce a QA layer somewhere between the activity authors and the users. Whether we thought it this way or not, bundles on ASLO are equivalent to distro packages. </pre> <blockquote type="cite"> <pre wrap="">And also most of activities come from individuals i.e. it's their masterpieces. So, lets talking about "forking" not about "taking over". </pre> </blockquote> <pre wrap=""> Ok, but we need to make sure that there's a way for one of these forks to become an automatic update for an abandoned activity. Moreover, there's the question of finding good names for activities. If the maintainer of Browse disappears, I wouldn't want to tell users: "now you should download BernieBrowse instead of Browse". </pre> <blockquote type="cite"> <pre wrap="">In my mind instead of increasing level of bureaucracy in sugar, for now, we could ping authors/nd publish forks on ASLO (with new bundle_id) and start implementing new Activities Library with taking into account all sugar specific (ASLO in case of AMO is not such, since Mozilla controls AMO addons and it is mostly centralized repo w/ QA etc). </pre> </blockquote> <pre wrap=""> I agree with you that we should keep bureaucracy to a minimum. I liked your proposal of creating per-deployment collections to manage a set of activities that has been tested and approved. I think this is one of the things Uruguay wanted. If we decided to go this path, what would be missing? Does our update API support collections? Can anyone create a collection easily? </pre> <blockquote type="cite"> <pre wrap="">I'm working on Activities Library (on early stage). It will look like: * server in the person of buddy in F1 view with shared instance of Library activity * any user can join this instance to see what activities are on the server * can just click to launch * can share new activity or fork of existed * any user can be such server, he just need to follow regular sugar practice, create new instance of Library and share it Any ideas are welcome <a class="moz-txt-link-freetext" href="http://wiki.sugarlabs.org/go/Activities/Library#Activity_Library">http://wiki.sugarlabs.org/go/Activities/Library#Activity_Library</a> </pre> </blockquote> <pre wrap=""> Fantastic project! Will it support multiple libraries, for the same of decentralizing things? I can imagine that many deployments would want a hierarchical thing to save bandwidth and delegate decisions to school principals: the schoolserver would be the first place where children search for activities, then would come the deployment server and lastly ASLO. I think dsd did something like this for the old updater. </pre> </blockquote> </body> </html>