On Tue, Jan 18, 2011 at 05:00:07PM -0500, Bernie Innocenti wrote: > On Tue, 2011-01-18 at 20:32 +0000, Daniel Drake wrote: > > > If I use a collection, the versions are fixed to the exact versions > > that I add to the collection, whereas (see last mail) I want the > > latest activity version compatible with Sugar-0.90. > > (please correct me if I've misunderstood what a collection is) > > The latest activity compatible with Sugar-X.Y is what the RDF protocol > provided. > > This wasn't considered good for deployments enough because it doesn't > allow the pedagogical team to do any QA on updates before they hit the > users. > > So the idea is that Dextrose could create a collection "dextrose2" which > pins certain activity versions. Paraguay could create a collection > "dextrose2-py" and pin slightly different activities. > > The downside of this approach is that development builds no longer get > the latest and greatest activities automatically. Is this what is > bothering you? Perhaps we could add separate microformat URLs that > filter by Sugar version.
> In my mind, letting the activity owner self-certify which versions of > Sugar are known to work well is poor QA practice. I'd rather have > someone responsible to do some testing upfront before blessing them for > the "sugar-0.90" collection. That depends on what side we are talking :), from deployment/distro pov, there is a need in [downstream] QA and collection is the right way (all activities need to be passed via such QA, if we talking about QA not just about letting deployment/distro users install some activities). My strong thinking is that ASLO should-not/impossible/useless be like a GNU/Linux distribution repository when all "packages" are well QAed and tested (it is perpendicular to sugar purposes when it is all about experiments and, thus, producing not-well-working/temporary solutions). ASLO is just a sharing place, we can have tens implementations of the same Record on ASLO (which is impossible in distribution repositories) from different doers and there [should not] is no any guaranties that all these implementations works well. If there is a need in guaranties, people work with particular doer (on improving particular activity) or create QAed/supporteded [downstream] collections. > Moreover, the version range currently supported by ASLO is a little too > simplistic for the variety of ABIs that we're going to see soon: > f14-s0.90-i386, f15-s0.92-arm... maybe even crazier. With multiple > architectures, the dream of a simple & universal bundle format for > activity is over and our package management tools are still very > immature. > > -- > // Bernie Innocenti - http://codewiz.org/ > \X/ Sugar Labs - http://sugarlabs.org/ > > -- Aleksey _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel