[Sugar-devel] Activities not compatible with Sugar-0.90

[Aleksey Lim]

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