[Sugar-devel] Fwd: Deployment of ASLOv3

James Cameron quozl at laptop.org
Tue Sep 4 19:32:55 EDT 2018


On Tue, Sep 04, 2018 at 10:46:48PM +0530, Jatin Dhankhar wrote:
>     I'm confused by your question, and have doubts as to success of your
>     plan.
> 
> You are right to doubt me, given that also3 is still not functional
> 
>      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?
>
> Only some. 

Thanks.  Until all function is replaced, I'll avoid changing Sugar or
Browse to use it, and keep activities.sugarlabs.org running.  ;-)

>     How would you like an activity maintainer to communicate the Sugar
>     version to aslo-v3?  [2]activity.info file?
> 
> For new versions of activities, if it can be done. Any heuristics to guess
> correct sugar version for old versions and activities.

I don't understand.  I'm the most frequent releaser of activities now.

Exactly how should I ensure that the next release of an activity is
properly marked with metadata so that only compatible versions of
Sugar will be offered the release?

The activity metadata specification, with changes proposed by Vipul,
is here;

https://github.com/sugarlabs/sugar-toolkit-gtk3/blob/f2a724caded6911a0a8de73362775ba74ef62c83/src/sugar3/bundle/__init__.py

>     How does an activity maintainer;
>     (a) include an activity, or;
> 
>     (b) exclude an activity? 
> 
>  By creating a release. No mechanism to exclude (expect from not
> releasing it)

Okay.  I create a release by creating a git tag of a specific form
(e.g. v7) and pushing the tag to the repository on GitHub.  I do not
click on "Draft a new release", because that would create the tag only
on GitHub, and someone else may change _master_ as I do it.  Releases
may not be in numbering order; e.g.
https://github.com/sugarlabs/browse-activity/releases

We need a mechanism to exclude an activity.  Please implement one.
Otherwise we'll have more activities move out of sugarlabs/ and into
user accounts; we already have a few for which sugarlabs/ only has a
clone; and loss of control is a key motivation for that.

>     How is a bundle supplied as part of release?
> 
> By attaching it in the release. https://help.github.com/articles/distributing-large-binaries/

Will this be added to setup.py or the bundle builder, or does it have
to be done by hand?

>      Is it hard, or is it that UI and UX are something that many people can
> 
> have an opinion on?  ;-)
> Latter is the main reason and not just restricted to frontend. 
> 
>     Which activities don't have SVG icons? 
> 
> My bad. All activities have svg icons. We are using Imgur for hosting images
> which sadly doesn't have support for svg, so we are converting the as base64
> encoded icons inside db. They look ugly though. 

There's no reason to use Imgur.  Use Sugar Labs.

>     "Activities".
> 
> Noted, just "Activities"
> 
>     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.
> 
> It's still hosted on sugar labs servers. I was talking about self hosting the
> javascript.

I'm talking about all resources fetched by a web browser; HTML, CSS,
JavaScript, PNG, and SVG.

>     https://wiki.sugarlabs.org/go/Summer_of_Code/2017 "Maintenance of
>     activities.sugarlabs.org (ASLO)" was what I thought you had begun
>     working on.  ;-)
> 
> Yes, I started with that in mind :sweat_smile: 
> 
>  
> There are lots of changes that need to be addressed.
>  I say, start with a issue, discuss solutions and start implementing, with a
> biweekly deadline ? 

Doesn't worry me how you manage it.

> If anyone like to address some issues or suggest solutions, please do so. Vipul
> is working on the frontend fixes.
> 
> Thanks,
> Jatin Dhankhar
> [...]

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


More information about the Sugar-devel mailing list