[Sugar-devel] New ASLO Project Definition

[James Cameron]

Composite reply to several posts, see text in quoted context below.

In summary;

- the translation of summary and description is already handled by
  sugar3.activity.bundlebuilder module,

- a root problem is loss of activity maintainers, and this effort
  won't fix that, so it will be wasted effort; we still won't have
  updated activities after it is finished,

- myself and other image builders have worked around the problem,

- it is the Fructose collection that is most critical; the set of
  demonstration activities that are included in every image,

- the regular Fructose activity developers in the past year were
  Walter, Sebastian, Alan, Sam Parkinson, Gonzalo, and myself;
  although both Sam and Gonzalo have signalled their disengagement,

- while we have retained new developers from GSoC and GCI, they have
  concentrated on the core rather than activities,

- automatic bundle creation will be vulnerable to subversion, and is
  not suitable for all activities.

On Thu, May 18, 2017 at 05:14:34PM -0400, Samuel Cantero wrote:
> I just realized that proposal wasn't send to sugar-devel list. It
> was removed from the thread at some point. So I just forward the
> link again. Sorry for people subscribed to multiple lists.

I've trimmed addressees.  No need to copy those extra people, they are
already on sugar-devel@, and no need to copy iaep@ because this is a
development discussion.

I've changed CC of Aleksey because their @sugarlabs.org address hasn't
been used for years, and I don't know if it works.

> https://goo.gl/VEIzCr

Copied and pasted below.

Please, in future, attach it or include it in mail, so that it can be
found in mailing list archives.  Links to external documents
eventually fail, and people may change them after the mail is sent.

> Outline for ASLO Version 3
> 
> Why a new ASLO?
> 
> * Developers should maintain up-to-date information of their
> activities in two places: the GitHub repository and ASLO. This has
> led to a very out-of-date ASLO. We can overcome this, giving
> developers the chance to only update the GitHub repository and
> forget about changes in ASLO.

No.  I disagree with the conclusion.  The reasons ASLO is out of date
are;

- there have been no new activity releases, because activity
  maintainers have left, and no new maintainers joined,

- those of us building images have bypassed activity maintainers by
  making point release bundles or applying patch collections.

The argument that ASLO is out of date because of there being two
places to update information ... is specious.  Besides, "two" is
wrong; there is a third place critical for downstream packaging;
download.sugarlabs.org.

As a consequence of losing activity maintainers, moving to one place
for updates won't fix the problems.

What Sugar Labs has not done is replace the activity maintainers that
have left.  The underlying problem is sustainability of an open
source community.  Nagia Eghbal of GitHub has recommended several
actions in her book "Roads and Bridges: The Unseen Labor Behind Our
Digital Infrastructure"

https://fordfoundcontentthemes.blob.core.windows.net/media/2976/roads-and-bridges-the-unseen-labor-behind-our-digital-infrastructure.pdf

"Some projects have experimented with making it easier to contribute."

Another project's policy "emphasizes growing the number of
contributors and empowering them to make their own decisions, instead
of treating maintainers as the final approving authority."

In a recently abandoned discussion of Sugar Labs goals;
https://wiki.sugarlabs.org/go/2017_Goals

For the goal "Develop, distribute, and maintain a variety of Sugarizer
Apps and installations for as many devices as possible", is an
objective "Actively recruit and maintain developers for Sugarizer",
and "Make the platform easier for developers to contribute" action
item.  Lionel gets it.  Yet nothing for Sugar desktop activity
maintainers.  And the Sugarizer activities are not being developed to
be portable back to Sugar desktop.

The role of an activity maintainer is to accept changes from others,
test the activity, iterate with fixes, update version, tag a release,
make a bundle, upload to ASLO, upload to download.sugarlabs.org, and
field any questions that arise.

Developers in the past year for the Fructose "set of demonstration
activities", are;

- Chat; Walter, Leonard, and myself,
- Browse; Leonard, Sebastian, and myself,
- Read; Walter, Leonard, and myself,
- Calculate; Walter, Leonard, myself,
- Log; Walter, and Leonard,
- Write; Walter, Leonard, and Gonzalo,
- Terminal; Leonard, and Sam Parkinson,
- Pippy; Leonard, Walter, Sebastian, Ignacio, and myself,
- Etoys; none,
- ImageViewer; Leonard, Walter, and myself,
- Jukebox; Leonard, Walter, and myself,
- Turtleart; Walter, Leonard, Alan and Sebastian,

My prediction is that this new effort is just going to make things
worse.  Few of you speaking in the debate are an activity maintainer
or developer.  You risk making a tool that nobody will use.

Please spend your time being an activity maintainer instead?

> * Current ASLO has activities in queue that have been never
> moderated. This is not an ASLO issue per-se, but rather due to the
> lack of people involved in reviewing new activities versions or new
> published activities. Certainly this was a good idea in the Sugar
> Labs beginnings, but it's not viable anymore.

It is my job to review activities before they are built into an image;
checking for malicious code, correct licensing, and correct function.

Nobody has asked me or added me to moderators queue.  Why not?  ;-)

I only recently found out that it existed; and it hasn't hindered the
critical activities.

> Actors and use cases
> 
> We mainly have three actors; students/teachers, developers and image
> builders.
>
> * Students/teachers must be able to search and download
> activities. Hence, we need to support activities searching and
> filtering.
> * Developers must be able to publish a new activity or a new version
> of an existing activity.
> * Image builders must be able to select a set of activities
> (collection) and generate an "update URL" - with activity
> information in semantic microformat [1] - that will be used for the
> building of a new XO image and for Sugar software updates.
> 
> Workflows
>
> How activities are going to be published for the first time?
> 
> 1.  Every activity should be hosted on GitHub inside a specific
> organization like: https://github.com/sugar-activities/. For
> instance, turtleart can be hosted at
> https://github.com/sugar-activities/turtleart. Hence, the only
> requirement to have a new activity published into ASLOv3 will be a
> repository under sugar-activities organization.

In the http://github.com/sugarlabs organisation;

- there are many activity repositories, and;

- there are very few non-activity repositories.

So it would be simpler to move the non-activity repositories to a new
sugar-core GitHub organization.

However, clones are cheap, so as long as the activity repositories
also stay where they are (either /sugarlabs/ or developer accounts),
there's no requirement for updating the repository metadata in
activity.info files.

> 2. Once repo is under sugar-activities organization, an event
> "Repository created" will trigger a webhook, i.e, GitHub will send a
> POST request in JSON format to a URL like
> https://aslo3.sugarlabs.org/hooks. This endpoint must process the
> payload sent by GitHub. It will provide the action (like "action":
> "created") and the repo URL.
> 
> 3. Based on previous information, ASLOv3 must get the latest release
> using GitHub API [2] - authentication must be done using OAuth
> (getting a token for the app). Once it has the latest codebase
> release locally in server, the XO bundle must be generated in the
> server along with the tar files (if applicable). All the information
> about the activity will be gotten from the activity.info file
> (activity metadata) [3] and from the GitHub payload. Developers
> (collaborators) can be gotten from GH API.

So just to clarify, you are removing from the activity maintainers the
right and duty to run "python setup.py dist_xo", and "python setup.py
dist_source", and you are _trusting_ the activity maintainers not to
place anything in setup.py to subvert or take control of your server?

On both counts, you are very brave.  Who runs this server?

There will be activities that cannot be processed in this way; such as
the Wikipedia activity.

There will be activities from maintainers who won't engage in this new
process; how will those activities be welcomed?

> How a new activity version is going to be published?
> 
> [...]
> 
> How an update URL with activity information in microformat should be
> generated?
> 
> [...]

I've no issues with the remainder of the proposal.  Good design.

On Fri, May 19, 2017 at 09:19:42AM +0800, Tony Anderson wrote:
> [...]
> I think there is a fourth, very important actor, the deployer. The
> deployer needs to configure a laptop installation but does not have
> the technical skills to build an image.

And they never ask for help, they never get any better skills.  No
other such people exist.  There's just you.  Everybody else has been
able to use the image building instructions and reach out for help.

And I disagree; there's no different actor; a deployer who can't use
image building instructions yet still builds an image on a laptop is
effectively an image builder using different tools.

> A practical solution is to flash a prebuilt image (e.g.  13.2.8) and
> then update the activity configuration as needed. The best help we
> could provide for the developer is a network install capability from
> the institution's lan.

No, it is almost always more time effective for groups of laptops to
build an image.

> Since James Cameron (and possibly Jonas Smedegaard) are the only
> image builders I know of, it seems hard to justify automation.
> Perhaps the scope of the 'update url' should be shifted to providing
> a build system that creates a Sugar image for various target
> systems.

My images are either Fedora 18 for XO-1, XO-1.5, XO-1.75, XO-4, or
Ubuntu 16.04 for NL3.

No, I don't think Jonas builds images.

Sebastian has built a Debian image.

Fedora builds a SoaS image.

I know of several others who build images, but I can't reveal their
identity here.  Their continued engagement has made the tooling
stable.

I don't think the user base is large enough for an image building web
service.

> Workflows
> [...]
> 3. I assume tar files are used in xol bundles.

No, tar files are used by Fedora, Debian and Ubuntu.

On Fri, May 19, 2017 at 09:57:30AM +0800, Tony Anderson wrote:
> The more difficult question is how to localize the summary and
> description of the individual activities. At present, it appears we
> don't attempt to localize this information.

No, the "python setup.py genpot" step implemented in BundleBuilder
does extract the summary and description for localisation.

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