[Sugar-devel] Fwd: Deployment of ASLOv3

James Cameron quozl at laptop.org
Tue Sep 4 01:07:04 EDT 2018


On Tue, Sep 04, 2018 at 09:01:42AM +0530, Jatin Dhankhar wrote:
> [...]
> That's a long of issues.
> Thank you James for taking out time and compiling the list. 
> I don't have a definitive strategy in mind.
> How about tackling them one issue at a time, each issue segregated into
> categories, with priorities ranging from important to enhancements. 
> I am not sure about many issues. 
> 
> 1.
> 
>     - a transition plan is needed, to explain how to handle the Fedora 18
>       systems running Sugar 0.112 and earlier,
> 
> Didn't get this one. Do we need to support older client with a
> minimal version of the website ? 

Hope so, otherwise it would not be used.

I'm confused by your question, and have doubts as to success of your
plan.

You've made a replacement for the currently working production service
activities.sugarlabs.org?  How much of the function is replaced?  All,
or only some?

I've had a quick look at the access logs for activities.sugarlabs.org,
for the past year.

This is a high traffic site, with 4,763,843 requests over the year.

I've excluded the web crawlers such as Google.

Most of the remaining requests are from Sugar, either the Software
Update feature in My Settings, the automatic updater, or the Browse
activity.

There were 147,489 requests from Software Update or the automatic
updater.  Version strings are included in user agent or as URI
arguments.  By version the request counts are;

0.100 (25,927),
0.102 (3,655),
0.104 (42,197),
0.106 (4,120),
0.108 (18,258),
0.110 (41,465), and
0.112 (11,918).

There were 2,246,274 requests from Browse.  By version they are;

0.98 (532,122),
0.100 (577,209),
0.102 (0),
0.104 (0),
0.106 (1,118),
0.108 (75,955),
0.110 (827,264), and
0.112 (232,611).

Based on these measurements, it is critical to support older clients,
by either;

(a) making sure aslo-v3 can do these requests properly, or;

(b) keeping activities.sugarlabs.org running.

> 2. 
> 
>     how to list the compatible Sugar versions for an activity release?
>       activities.sugarlabs.org asks for this when uploading an activity,
>       and it works well with the Browse presentation of Sugar version
>       through the user agent string,
> 
> Right we are using a simple heuristics to determine min sugar version for an
> activity
> https://github.com/sugarlabs/aslo-v3/blob/master/aslo/api/release.py#L231
> We currently don't log and use agent strings 

Thanks.

At the moment, during upload to activities.sugarlabs.org, an activity maintainer
chooses the range of Sugar versions.

How would you like an activity maintainer to communicate the Sugar
version to aslo-v3?  activity.info file?

We can't change how existing laptops or desktop computers send the
agent strings, so if you need to be compatible with them you must use
the agent strings in the same way.

> 3.  
> 
>      how to handle activities like Tam Tam, Fortune Hunter, Wikipedia and
>       soon Turtle Art, where the git repository makes more than one
>       activity bundle?
> 
>  Not sure about how different bundle works, for now we are using following 
> https://github.com/sugarlabs/aslo-v3/blob/master/activity-build-docker/
> Dockerfile#L8 to generate .xo for source activity. If bundle is supplied as
> part of release we give it preference (since the author attached that and
> wanted to release it)

Please read the repositories to find out how multiple bundle
activities work in detail.  In brief, more than one bundle is made
from the repository, and it isn't always by use of setup.py dist_xo.

How is a bundle supplied as part of release?

> 4.
> 
>      how to handle activities like Browse, Measure, Speak, and Record,
> 
>   where non-master branches are used to make bundles compatible with
>   different systems,
> 
> I think we took care of the branch. But different branch (i.e multiple
> branches) for different systems are not supported, since it means different
> bundles for a single activity. This needs to worked upon.

Thanks, please do.  The reason for using different branches is so that
different bundles can be made for each different system.

I've tried to make sure the README.md of the affected repositories
list the branches.  For instance for Browse;

https://github.com/sugarlabs/browse-activity/blob/master/README.md

> 5.
> 
>     many activities are missing; e.g. Record,
> 
> Yes, not all activities are included

How does an activity maintainer;

(a) include an activity, or;

(b) exclude an activity?

>  6.
> 
>     an activity version number is not shown; workaround is to hover over
>       the download link, but this doesn't work in Browse because the link
>       URL is not shown,
> 
> Yes, we can add version on the UI as well. Hardest part is to settle on a
> definitive and consistent UI.

Is it hard, or is it that UI and UX are something that many people can
have an opinion on?  ;-)

The reason for activity version is so that a user may quickly
determine if a new version is available.

> 7. 
> 
>      blurred icons; these are embedded PNG instead of SVG, and so when
>       they scale up they blur,
> 
> Yes, not many activities have svg icons.

Which activities don't have SVG icons?  They are each supposed to have
one; activity.info config file metadata "icon" should point to an SVG
file in the same directory.  For example in Browse;

https://github.com/sugarlabs/browse-activity/blob/master/activity/activity.info#L5
https://github.com/sugarlabs/browse-activity/blob/master/activity/activity-web.svg

> 8. 
> 
>     page title is "Software Center | SugarLabs"; (a) don't think
>       "Software Center" is the right name; was there consensus?  (b) this
>       must be internationalised for more languages than "es" and "hi", and
>       (c) "SugarLabs" should be "Sugar Labs",
> 
> What should be the right name ? 

"Activities".

> 9. 
> 
>     in the detail view, the icons for the headings are too close to the
>       text, e.g. "<spiky circle>Activity" and "<pancake stack>Details",
> 
> Yes, that is an easy fix. Adding margin to font-awesome icons.

Thanks.

> 10. 
> 
>     at the bottom of the page, the links to "Sugar Labs", "Development",
>       and "Resources" do not work,
> 
> Yes, not every link was decided. Easy fix.

Thanks.

> 11.  
> 
>     the general layout of the page is unlike the other services at Sugar
>       Labs, as if there is no central theme,
> 
> Yes, that is one of the biggest issue, a consistent theme.

I don't think it is a big issue.  We have several consistent themes to
choose from!  ;-)

>  12. 
> 
>     Browse on Fedora 18 reports several instances of "Cross-origin
>       script load denied by Cross-Origin Resource Sharing policy.", and
>       the page does not finish loading,
> 
> Didn't test it on browse. Major browsers didn't complain about this.

As most of the users of activities.sugarlabs.org are using Browse, and
most are using an old version, you should test with Browse.

Major browsers are much less important for a site such as this.

> 13.  
> 
>     many off-site resources are used; such as
>       https://cdnjs.cloudflare.com/ajax/libs/mdbootstrap/4.3.2/js/mdb.min.js
>       these must be local so as to avoid multiple DNS queries, to allow
>       port proxied use, and to pipeline requests.
> 
> Self hosting is on the list. I thought having a CDN resource will improve the
> performance and reduce latency. 
> How about use both with cdn as fallback.

Sugar Labs has servers.  I'm not concerned about _where_ the site is
hosted, except that it should be under the control of Sugar Labs.  The
performance will rely on all the resources of the site being either
embedded or on the same server.

>     For interest, an automated publishing tool for
>     activities.sugarlabs.org is available at
>     https://github.com/sugarlabs/sugar-tools/blob/master/activity-publish
> 
>     This tool decreases the time between "git tag vN" and activity
>     available for download to a few seconds, and leverages our existing
>     infrastructure.
> 
> Didn't knew about publish. 
> I wanted to integrate aslo-v3 closely with Github, so I followed that route.  
> 
> I might be wrong about lots of things. Do let me know.

You've made good steps toward a goal, let's not lose that work, but
build on it and approach success.

https://wiki.sugarlabs.org/go/Summer_of_Code/2017 "Maintenance of
activities.sugarlabs.org (ASLO)" was what I thought you had begun
working on.  ;-)

> 
> Thanks,
> Jatin Dhankhar
> [...]

-- 
James Cameron
http://quozl.netrek.org/


More information about the Sugar-devel mailing list