[Sugar-devel] ASLO QA process

[Walter Bender]

On Thu, Apr 29, 2010 at 8:46 AM, Bernie Innocenti <bernie at codewiz.org> wrote:
> El Sat, 24-04-2010 a las 07:19 +0000, Aleksey Lim escribió:
>> 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).
>
> 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.
>
> 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.
>
>
>> And also most of activities come from individuals i.e. it's their
>> masterpieces. So, lets talking about "forking" not about "taking over".
>
> 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".

I filed a ticket (#1968) that speaks to this issue in part: by
disassociating the user-facing name from the bundle name, we have a
lot more flexibility.

>
>> 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).
>
> 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?
>
>
>> 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
>> http://wiki.sugarlabs.org/go/Activities/Library#Activity_Library
>
> 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.
>
> --
>   // Bernie Innocenti - http://codewiz.org/
>  \X/  Sugar Labs       - http://sugarlabs.org/
>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>



-- 
Walter Bender
Sugar Labs
http://www.sugarlabs.org