<!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"> Alexsey; Maybe simple preliminary workaround for incompatible activity downloads: Could a Group of working activities be created for each sugar version ie 0.84/0.86/0.88 to be selected by user on opening ASLO? Tom Gilliard satellit Bernie Innocenti wrote: <blockquote cite="mid:1276691650.2159.337.camel@giskard" type="cite"> <pre wrap="">El Tue, 15-06-2010 a las 22:31 +0000, Aleksey Lim escribió: </pre> <blockquote type="cite"> <pre wrap="">Here it is my preliminary TODO (not prioritized list): * Support(revert) of per architecture uploads, there are bunch of activities that are binaries and having requirement to have all supported blobs could be overkill for uploaders. </pre> </blockquote> <pre wrap=""> +1 </pre> <blockquote type="cite"> <pre wrap="">* Support per languages uploads. In some cases (GCompris, OOo4Kids) all languages in one bundle weights too much and per locale bundles makes sense. While downloading, ASLO will suggest only current locale bundle. </pre> </blockquote> <pre wrap=""> +1 (does upstream remora already provide this?) </pre> <blockquote type="cite"> <pre wrap="">* By default, ASLO just an repository of activities (not regarding their stability status) and anonymous downloading is required (for now, experimental downloads requires be logged in). </pre> </blockquote> <pre wrap=""> +1 on allowing anonymous download of any bundle, regarding its stable/experimental status. -1 on showing experimental activity bundles as the default download for activities. Probably, even maintainers should go through a peer review process. </pre> <blockquote type="cite"> <pre wrap="">* Current QA[1] scheme is too weak for deployment(various) needs and having previous option, more reliable scheme is required. Current plan is implementing QA profiles. Every activity could be stamped (from -n to +n) in several QA profiles. QA stamp is not part of activity itself and could be set by QA editors in any time. User can nominate activity to be stamped in several QA profiles to notify QA editors about new activity. QA editors will be notified about new version of already stamped activities via aslo@. </pre> </blockquote> <pre wrap=""> Perhaps a simpler scheme to implement, which would be sufficient to fulfill our needs would be adding the ability to specify exact versions of bundles in collections. Then, we could simply point the updater to a page like this: <a class="moz-txt-link-freetext" href="http://activities.sugarlabs.org/en-US/sugar/collection/f11-xo1-0.88">http://activities.sugarlabs.org/en-US/sugar/collection/f11-xo1-0.88</a> The deployment people would keep the versions updated after doing their QA on activities. </pre> <blockquote type="cite"> <pre wrap="">* Support microformat for OLPC updater. Also support collections as microformat groups. Take into account QA profiles. </pre> </blockquote> <pre wrap=""> +1 </pre> <blockquote type="cite"> <pre wrap="">It could be not full list of required features. If you are interested in some ASLO improvements, post an comment. </pre> </blockquote> <pre wrap=""> Thanks Aleksey, recapitulating this list of requirements was indeed very helpful. I'll try to find a php developer to help out implementing these features ASAP. Can we make them work in the activities-devel sandbox on sunjammer? </pre> <blockquote type="cite"> <pre wrap="">[1] <a class="moz-txt-link-freetext" href="http://wiki.sugarlabs.org/go/Activity_Library/Editors/Policy">http://wiki.sugarlabs.org/go/Activity_Library/Editors/Policy</a> </pre> </blockquote> <pre wrap=""> </pre> </blockquote> </body> </html>