[Sugar-devel] Mode of distribution of Sugar Activities

[James Cameron]

On Tue, Jun 30, 2020 at 09:50:45AM +0300, Srevin Saju wrote:
>     Remember that in my design for aslov4, it must "support activity
>     bundles uploaded via ssh,"
> 
> I have seen and read the GSoC guidelines. I have also noticed that
> aslov4 should support activities uploaded by ssh. But it is almost
> impractical in my case. I do not own a ssh server so I cannot build
> / deploy a server / storage where I could publicly give ssh access
> to developers at sugarlabs. The best I could do is to make use of a
> free service (in this case, GitHub; but I have also mentioned of the
> alternatives to GitHub in my first email, (because personally I do
> not prefer Github too). If in case, I get access to a free ssh
> server on Google Cloud Platform or something, I will extend this
> feature.  Because, I cannot implement a feature which I cannot test.

You can SSH into your computer for testing.  Look for a way to add SSH
server listening on localhost address, yet refuse on your external IP
addresses.

You can also SSH into a VM or chroot on your computer.

We also have sunjammer.sugarlabs.org which provides SSH access for
activity maintainers.  That's how the tarballs are provided in
download.sugarlabs.org and some bundles in people.sugarlabs.org.

> But this is absolutely possible, because sugarappstore-generator
> script is modular, I can easily provide the bundle location and it
> can automaticaly generate the static location. In this case, a
> custom `list_activities` needs to be defined to find uploaded
> bundles.

Good.  Are there instructions for how I can deploy this to sunjammer?

>     and may also "for a specific list of
>     activities, access the source repository and detect any change to a
>     release tag (publish), create a bundle and extract release notes,"
> 
> I am not sure if you have noticed, I have added support for all
> activities to extract the release notes from the current tag. The
> problem with some repositories is that, they do not use annotated
> tags, so I cannot extract the Release notes from the tags. But I am
> able to extract the Release Notes from activity NEWS. I added this
> feature in the past week, maybe it went unnoticed.

I don't like having the creation of a version tag cause things like
this to occur.  It will just encouarge me not to use tags.

A current version tag is not a usable concept, especially for
repositories with multiple branches, that's why "release tag
(publish)" is said; so that a tag like "publish" or "aslov4" might be
used instead.

Yes, we don't typically annotate tags, but we do often have brief
release notes in the commit that is tagged.

Parsing from NEWS is probably sufficient for this specific list of
activities.  I don't imagine it will number more than about 20.

> To do some special testing / checking / checking out some commit or branch on
> the activity, the generator gives the option as given below
> 
> ```
> 
>   --build-entrypoint BUILD_ENTRYPOINT
>                         Specify a path to any Linux compatible script which is
> intended to be executed on every build
>   --build-override      Override `python setup.py dist_xo` with
> --build-entrypoint argument shell script
>   --build-chdir         Changes directory to Activity dir
> 
> ```
> 
> It implies, we could feed a custom build script, instead of using `python
> setup.py dist_xo` . So I hope that would do!
> 
> The idea of automatic building was to
> 
>   • increase the quality of activity (I will extend this to testing activities,
>     (make sure it starts) using Continuous Integration)

I don't like the idea of automation that removes responsibilities of
an activity maintainer.

>   • an activity built on your system, should be equally built on another
>     developer's system (i.e should be reproducible)

I don't see why we need to have bundles reproducible.  Bundles are
made so infrequently.

>   • Reduce the time needed by developers to manually fill in the details and,
>     upload binaries etc etc. I have used the exact same principle used by the 
>     [1]https://appimage.org You can see their pull requests, which
>     automatically tests if the appimage would work on Ubuntu Xenial (the oldest
>     LTS).

Scripting easily handles uploads.  For Python 3 activities, I'd just
use scp or rsync of the bundle file.  I have this in my local scripts
already.

For Python 2 activities, it was way more complicated than I wanted;
because of aslov1, see
https://github.com/sugarlabs/sugar-tools/blob/master/activity-publish

I don't want to be in a situation where release is dependent on a
large collection of tools that have to work just right.  It can get
fragile, and we don't release activities enough to justify that
fragility.

> Please let me know if there is anything I can do. I will try to get a server
> (temporarily) to add the ssh feature.
> 
> On 30/06/2020 09:24, James Cameron wrote:
> 
>     On Tue, Jun 30, 2020 at 12:22:41AM +0300, Srevin Saju wrote:
> 
>         Thanks
> 
>             Yes, there is no single source of Python 3 activity bundles.  There
>             was for Python 2 activities; it was activities.sugarlabs.org.
> 
>         I hope aslov4 would solve this issue. I have now uploaded entire
>         successfully built Python3 bundles to
>         [2]https://github.com/srevinsaju/sugar-activity-build/ releases. You
>         can check them out if you are interested and get some spare time.
> 
>     Thanks.  That there is no single source of Python 3 activity bundles
>     doesn't really cause a problem for me.  I don't need aslov4 to fix it.
>     There's more to the dependency problems than Python version.  That's
>     why I said in the aslov4 idea "(a) ported to Python 3 and released,
>     and (b) tested on Sugar Live Build."
> 
>             Yes, there is no single source of activity sources.  Best we have is
>             GitHub sugarlabs org, where directory activity has a file
>             activity.info which has a valid exec key.  But also gitorious.
> 
>         By 'no single source', is there any instance of python3 activities on
>         gitorious?
> 
>     You'd have to look.  I don't know of any.  Ibiam is probably right,
>     but as Gitorious is still open, commits may be pushed, and so there is
>     a possibility that a repository there may contain activity source
>     compatible with Python 3.  I don't think you need to concern yourself
>     with it though.
> 
>         I wanted to know if all the python3 activities are either forked or
>         owned as a repository at sugarlabs GitHub organization? or does it
>         still exist at some other places?
> 
>     You'd have to look.  There can be activities for Sugar that are not
>     part of the GitHub sugarlabs organisation.  We have seen several over
>     the years, and we try to fork them, but there's no guarantee that we
>     have been successful.  I don't think you need to concern yourself
>     with it though.
> 
>     Remember that in my design for aslov4, it must "support activity
>     bundles uploaded via ssh," and may also "for a specific list of
>     activities, access the source repository and detect any change to a
>     release tag (publish), create a bundle and extract release notes,"
> 
>     I'm looking forward to those two features in particular.
> 
>     Some source repositories are used to make multiple activity bundles;
>     Wikipedia and TamTam are examples.
> 
>     I'm not interested in GitHub integration, because I don't always use
>     GitHub, and some of the use cases for aslov4 are for situation where
>     no internet access is available.
> 
>             Yes, aslov4 as specified in our GSoC project idea could look like it
>             was a smaller than normal project, but if you iterate through each of
>             the requirements it could easily fill the time available for a GSoC
>             student working for 12 weeks of seven hours a weekday.
> 
>         Yes I agree. ASLOv4 is not an easy task. I am not sure when Manish
>         (radii.dev) would be free, I will try to complete the best I can, to
>         my knowledge.
> 
>     Thanks.
> 
> --
> V/r
> Srevin Saju
> 
> References:
> 
> [1] https://appimage.org/
> [2] https://github.com/srevinsaju/sugar-activity-build/

pub   RSA 4096/66D390D7 2020-05-19 Srevin Saju (srevinsaju) <srevinsaju at sugarlabs.org>
> sub   RSA 4096/14479587 2020-05-19
> 




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