<html> <head> <meta content="text/html; charset=utf-8" http-equiv="Content-Type"> </head> <body text="#000000" bgcolor="#FFFFFF"> <div class="moz-cite-prefix"> 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. <meta name="Description" content="Copy-Paste Buffer"> <meta name="Generator" content="Zim"> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> 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: </div> <blockquote cite="mid:20170519070407.GM15330@us.netrek.org" type="cite"> <pre wrap="">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: </pre> <blockquote type="cite"> <pre wrap="">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. </pre> </blockquote> <pre wrap=""> 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. </pre> <blockquote type="cite"> <pre wrap=""><a class="moz-txt-link-freetext" href="https://goo.gl/VEIzCr">https://goo.gl/VEIzCr</a> </pre> </blockquote> <pre wrap=""> 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. </pre> <blockquote type="cite"> <pre wrap="">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. </pre> </blockquote> <pre wrap=""> 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<a class="moz-txt-link-rfc2396E" href="https://fordfoundcontentthemes.blob.core.windows.net/media/2976/roads-and-bridges-the-unseen-labor-behind-our-digital-infrastructure.pdf">" https://fordfoundcontentthemes.blob.core.windows.net/media/2976/roads-and-bridges-the-unseen-labor-behind-our-digital-infrastructure.pdf "</a>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; <a class="moz-txt-link-freetext" href="https://wiki.sugarlabs.org/go/2017_Goals">https://wiki.sugarlabs.org/go/2017_Goals</a> 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? </pre> <blockquote type="cite"> <pre wrap="">* 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. </pre> </blockquote> <pre wrap=""> 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. </pre> <blockquote type="cite"> <pre wrap="">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: <a class="moz-txt-link-freetext" href="https://github.com/sugar-activities/">https://github.com/sugar-activities/</a>. For instance, turtleart can be hosted at <a class="moz-txt-link-freetext" href="https://github.com/sugar-activities/turtleart">https://github.com/sugar-activities/turtleart</a>. Hence, the only requirement to have a new activity published into ASLOv3 will be a repository under sugar-activities organization. </pre> </blockquote> <pre wrap=""> In the <a class="moz-txt-link-freetext" href="http://github.com/sugarlabs">http://github.com/sugarlabs</a> 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. </pre> <blockquote type="cite"> <pre wrap="">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 <a class="moz-txt-link-freetext" href="https://aslo3.sugarlabs.org/hooks">https://aslo3.sugarlabs.org/hooks</a>. 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. </pre> </blockquote> <pre wrap=""> 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? </pre> <blockquote type="cite"> <pre wrap="">How a new activity version is going to be published? [...] How an update URL with activity information in microformat should be generated? [...] </pre> </blockquote> <pre wrap=""> 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: </pre> <blockquote type="cite"> <pre wrap="">[...] 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. </pre> </blockquote> <pre wrap=""> 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. </pre> <blockquote type="cite"> <pre wrap="">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. </pre> </blockquote> <pre wrap=""> No, it is almost always more time effective for groups of laptops to build an image. </pre> <blockquote type="cite"> <pre wrap="">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. </pre> </blockquote> <pre wrap=""> 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. </pre> <blockquote type="cite"> <pre wrap="">Workflows [...] 3. I assume tar files are used in xol bundles. </pre> </blockquote> <pre wrap=""> No, tar files are used by Fedora, Debian and Ubuntu. On Fri, May 19, 2017 at 09:57:30AM +0800, Tony Anderson wrote: </pre> <blockquote type="cite"> <pre wrap="">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. </pre> </blockquote> <pre wrap=""> No, the "python setup.py genpot" step implemented in BundleBuilder does extract the summary and description for localisation. </pre> </blockquote> </body> </html>