[Sugar-devel] New ASLO Project Definition

[Tony Anderson]

Thanks very much for this. I am optimistic that our path is converging.

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

     The best problem is one that is already solved.

* The root problem is the loss of activity maintainers.

             Couldn't agree more. Hopefully by next-year's GSOC, we can 
have more focus on the roles of activity maintainer and activity developer.


Thanks for the list of Fructose activities, I have been trying to find a 
definitive list since the issue was raised.

I agree with your handling of the distribution. Walter has also made the 
point in the GSOC meetings to use sugar_dev.

Your comments about 'Why a new ASLO' have cleared up a lot for me. I see 
ASLO as a place where Sugar users go to get new activities to install on 
their laptops. As an image builder, you are properly focused on the core 
set of activities you need to include.

So I see this three-month project as providing a new implementation of 
the distribution function of ASLO,  while support for activity 
developers and maintainers moves to github.

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

Won't take the bet. It won't make things worse, but it could be a waste 
of time.  However, I am very optimistic because of the level of 
attention this project has already gained. This is the best insurance 
for a useful design and postive outcome.

As I see the activity development procedure:

Just as for Sugar core, a change to an activity would be requested by 
the developer and then tested by a maintainer. If acceptable, a new 
version would be committed as a branch with a message such as 'v23'. At 
this point the maintainer makes the xo bundle and copies it to the 
download.sugarlabs.org/activities
directory. ASLO would show the new bundle as the 'latest'.

A new activity could be developed in a personal github repository. The 
developer, when ready, can request it to be made a repository on the 
Sugar activities github. This would be done by an activity maintainer 
with 'owner' permissions.

Tony

On 05/19/2017 03:04 PM, James Cameron wrote:
> 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.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20170519/d4097f9c/attachment-0001.html>