<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> </head> <body text="#000000" bgcolor="#FFFFFF"> <div class="moz-cite-prefix">With the help of Google, I was able to find the 0.112 page. Note that <a class="moz-txt-link-abbreviated" href="http://www.sugarlabs.org">www.sugarlabs.org</a> has a link 'get sugar'; however, this link mentions only 0.110. Debian supports 0.112 with Buster, a version in testing. Ubuntu is waiting for the release of Buster. Fedora 28 is scheduled for release in May 2018. I was unable to find a reference to a live build on the 0.112 page. The only reference to the XO is: <h3>"Fedora 18 on OLPC XO</h3> For OLPC XO laptops, using OLPC OS 13.x (Fedora 18), use the OLPC packages, and update only the Sugar packages to 0.112.olpc.x, like this: <pre>sudo yum update sugar* sudo service olpc-dm restart" </pre> I won't quibble about the one command. However, this process requires that the XO be connected to the internet. It is possible to install a version of Yum on the XO that supports a downloadonly option. This option downloads and shows the rpms required by the update. With an unreliable internet connection with download speed of 56kb, installing 0.112 on multiple machines requires a method to install by local files. However all of this begs the question, why is this so damn difficult? A command line tool olpcosbuild with three arguments: model, version, and activities could generate an installable image (.zd and .zip) for the selected model. Models are XO1, XO1SD, XO1.5, XO1.75, XO4. Versions are 0.112 or latest. The third argument names a text file in the local directory which lists the activities to be installed, e.g. Browse 157.2 Record latest TurtleBlocks latest For Debian, a similar command line tool debianbuild with two arguments: version and activities. This would produce a debian package installable on any standard computer which supports dpkg. Options could be provided for --stretch, --buster, --raspbian. With these tools, we could install and test or use a new version of Sugar at any time without any knowledge of GitHub, pull requests and the like. Users could report issues which developers could reliably and conveniently reproduce. Tony On Saturday, 16 December, 2017 11:04 AM, James Cameron wrote: </div> <blockquote type="cite" cite="mid:20171216090423.GA17361@us.netrek.org"> <pre wrap="">Yes, you can extract the source code for the 0.110 release and apply fixes, but nobody seems to want to do that, which is no surprise as 0.112 is the stable release now. Many bugs were fixed. Yes, Sugar was released as 0.112. At the same time a Sugar Live Build was released, which can be booted or installed on any standard PC or laptop. Users with OLPC OS 13.2.8 can install Sugar 0.112 very easily; one command. Users with OLPC OS 16.0.4 can install Sugar 0.112 very easily; with a GUI or two commands. All this is on the Wiki page for 0.112. Fedora SoaS was stabilised without including Sugar 0.112, and the next version of SoaS will likely have it. Our hard working Fedora packagers are busy and sometimes miss announcements. Next versions of Debian, Ubuntu and Fedora will also have Sugar 0.112, if the developers of those projects continue in the way they have before. Sugar 0.112 is indeed a release, and as I said above, is available for users and integrators, not just developers. No, there is nobody looking at providing Fedora 27 for the XO. Such an effort would need huge resources. I've complained that ASLO does not have maintainers; yes, and we have called for maintainers in the most recent GSOC, and gave maintenance as an option, but the outcome was to engineer yet another version of ASLO. It is not released. I've also complained that activities do not have maintainers; and that is a problem of greater severity. More and more activities no longer work. I'm hard pressed to keep even the core set of activities tested and working. A thankless task. I think we do understand that potential contributors are not Sugar users. It is very evidence as they speak of their plans or make pull requests. We lack testers because nobody has the resources to test with. We have provided a release, in October, and it is complete and stable. Yet we have no testers testing it. No, I cannot countenance making an OLPC OS release that is not tested. So I take it you have refused Sugar 0.112 stable. That's good to know, and it confirms what I had already suspected; there are no people interested in Sugar 0.112 stable or the Sugar Live Build, and so there are almost no people who need a new OLPC OS release with Sugar 0.112 in it. All our major customers of OLPC OS make their own builds, and these automatically include Sugar 0.112. I'll change my opinion if I see good evidence of testing. On Sat, Dec 16, 2017 at 08:57:36AM +0200, Tony Anderson wrote: </pre> <blockquote type="cite"> <pre wrap=""> What I mean by version control in this context is that git can extract the source code matching the 0.110 release. This would enable bugs reported against 0.110 to be reproduced and corrections applicable to 0.110 to be made and released immediately. The subject of this thread: Migration from bugs.sugarlabs.org to Github was responded to appropriately. What was missed is the 'Migration from bugs.sugarlabs,org to Sugar'. Somehow we have become fixated on the notion that once code is merged into GitHub, the job is over. I certainly don't understand your statement that Sugar was released as 0.112. The release '[1]16.04.4 is an OLPC OS release The target platform is [2]NL3 only.' and does not mention what version of Sugar is provided. The releases for SOAS, Debian (including Raspberry Pi), Ubuntu, and Fedora are all 0.110. So far 0.112 is only available to developers who are presumably changing it - so how can that be called a release? Incidentally, SOAS is 0.110 on Fedora 27 - is anyone looking at providing Fedora 27 for the XO? Clearly one of the challenges in recruiting help is that any changes are not available even a year (13.2.8 is dated 12/12/2016) after they are made. What reward does a contributor get in seeing pull requests integrated in a GitHub repository? Most expect the changes to be available to the hundreds of thousands of users in the field. This is no problem for GSOC and GCI participants - they have other compensation. Further, one of the reasons most of our contributors are part of GSOC and GCI is that we provide no comparable path for independent contributors. If someone inquires, they are told to find a bug and fix it. We don't provide anything like the GSOC or GCI task list as areas where we could use help. You complain that ASLO does not have maintainers - have we ever suggested to a potential contributor that this is an area where we need help. We don't seem to understand that potential contributors are not Sugar users, probably have never seen an XO and so have no way to understand a bug report. Just as with GSOC and GCI, new contributors will need mentors to assist them getting started and to keep them interested. Naturally, we lack testers. We haven't provided a release to test in over a year. Further we motivate testers by a system that ensures corrections to problems they report will be made available 'tomorrow' (as in 'tomorrow, you are only a day away). If you want testers, make a release that can be installed in the field without special technical expertise. How about a OLPC OS build offered as a 'nightly'? A tester is a user who reports problems with the software he or she is using. Tony On Friday, 15 December, 2017 10:40 PM, James Cameron wrote: G'day, Sorry if you think it obvious, but some of what you say doesn't make sense to me. I'll try to respond though. I hope anyone else who understands your points better might comment. Purpose of git is to provide version control, and "git log" shows the exact history of changes of what is different in a new release of Sugar. GitHub is a visualisation of git, as well as a social media concentrator for workflows that involve git. For instance [3]<a class="moz-txt-link-freetext" href="https://github.com/sugarlabs/sugar/commits/master">https://github.com/sugarlabs/sugar/commits/master</a> shows the exact history of changes for the Sugar desktop shell. Each change is exactly described. The same view on other repositories show exact changes for other components of Sugar, such as the toolkit, datastore, and activities. Therefore I disagree that with GitHub we cannot maintain version control; we have full control of version of the source code. But I'm not sure this is what you intended to say. Now, the reason it is not possible to fix 0.110 is that we have already fixed it, and released as 0.112.We face great challenges in having anybody work on Sugar, except for contestants, so we must guide their work to the latest Sugar. It makes no sense to fix 0.110, we should instead fix 0.112. Sugar Labs does provide support for the current release 0.112. Neither git nor GitHub are directly involved in the construction of OLPC OS 13.2.8 or 13.2.9. So your concerns about GitHub have nothing to do with OLPC OS. Nobody has taken steps to get help from the WebKit project to fix bugs on Fedora 18. No such steps could be taken, because we would be laughed at and ignored. The root cause is lack of resources, and only an increase in resources could fix it. On Fri, Dec 15, 2017 at 09:29:34PM +0200, Tony Anderson wrote: Hi, James "Sorry, I don't understand what you are saying about GitHub.' I would have thought this was obvious. THe porupose of GitHub is to provide version control so that it is possible to tell from the history of changes what is different in a new release. As you said, it is not possible to fix 0.110 or 13.2.8 becasue of our inabliity to relate changes to the version against which the change was made. I suspect Sugar may be the only open source project which is unable to provide support for its current release. What steps has Sugar-devel taken to get help from the WebKit project to fix these bugs in Fedora 18? Tony On Friday, 15 December, 2017 08:27 AM, James Cameron wrote: Thanks for that. I expected there would be no resources. When I release a 13.2.9, it will be based on Fedora 18. Using a more recent version of Fedora requires resources that aren't available here either. No, 13.2.9 and Fedora 18 won't support the WebKit2 verson of the Browse activity, because WebKit2 on Fedora 18 is very buggy. Browse-157.4 has all the new features of Browse-201.3 except for WebKit2 support. Sorry, I don't understand what you are saying about GitHub. On Fri, Dec 15, 2017 at 06:59:10AM +0200, Tony Anderson wrote: Unfortunately, resources are not available here to test 0.112 on an XO. In the past we have moved to the most recent build released by OLPC. There is no urgency since this year we will have to continue with 13.2.8. Do you propose to release a 13.2.9 based on Fedora 18 or some more recent version? Will 13.2.9 support the WebKit2 version of the Browse.activity? It seems ironic that in moving to github, we can no longer maintain version control. I am not sure that I understand the technical issue in using 13.2.8 to obtain source copies of Sugar 0.110 for github. This should enable github to perform its essential role to make visible the history of subsequent changes. Tony On Friday, 15 December, 2017 05:24 AM, James Cameron wrote: I've checked, and there has been no testing of Sugar 0.112 on XOs since it was released on 9th October. Without any independent testing, I can't afford the risk of releasing a 13.2.9 with Sugar 0.112. [4]<a class="moz-txt-link-freetext" href="http://wiki.sugarlabs.org/go/0.112#Fedora_18_on_OLPC_XO">http://wiki.sugarlabs.org/go/0.112#Fedora_18_on_OLPC_XO</a> explains how to update to Sugar 0.112 on an XO. Then use My Settings, Software Update, to update the activities. On Fri, Dec 15, 2017 at 06:43:57AM +1100, James Cameron wrote: No, I don't think our technique is capable of fixing bugs in 0.110. No, I don't think the XOs will be limited to 13.2.8, and 0.112 is already available for XOs. We do seem to be limited as a community in how 0.112 is being tested to ensure there are no new bugs. On Thu, Dec 14, 2017 at 03:52:22PM +0200, Tony Anderson wrote: Is our bug-fixing technique capable of fixing bugs present in 0.110? It appears the the XOs will be limited to 13.2.8 and 0.110 for the forseeable future. Tony On Thursday, 14 September, 2017 10:39 AM, James Cameron wrote: Thanks for the idea. If someone is available to do it, great. A quick bulk insert of issues could be done using the GitHub API, or it could be done by hand by someone who knows nothing about Sugar. But it feels like unrewarding and wasted work, and there is more important work to do, such as fixing bugs or developing features. We have no plans to shut down the Trac instance bugs.sugarlabs.org and lose access to all those ideas. Also moving them to GitHub seems very unlikely to accelerate the rate at which tickets are resolved. Firstly, because the very people who might resolve tickets are busy moving tickets. Secondly, because those of us who are resolving tickets are able to do so with either bugs.sugarlabs.org or GitHub issues. Where the issue is lodged has no relevance to fixing it. We also lack regular testing and reporting of new issues; either in bugs.sugarlabs.org or GitHub issues. It has been nice to see GitHub used more, but mostly that is because of account approval delays on bugs.sugarlabs.org. There are some bugs.sugarlabs.org bugs that we may never fix, because the person who wanted them isn't interested any longer. Bringing those bugs into GitHub issues could be disruptive and unnecessary. On Thu, Sep 14, 2017 at 08:10:00AM +0000, Utkarsh Tiwari wrote: Hi everyone, While going through [5]<a class="moz-txt-link-freetext" href="https://bugs.sugarlabs.org">https://bugs.sugarlabs.org</a> today, I came across a lot of tickets that were raised quite a long time back ( > 2 years). I was wondering if we could do a GCI task of raising those tickets into their respective Github respositories which can accelerate the rate at which our tickets get resolved. This way newcomers while going through the SugarLabs repositories will be able to easily spot the issues regarding the specific repo they are watching. As not everyone is aware of our bugzilla, this could be a nice alternative to catching contributor's attention to raised tickets. What do you all think? Regards, Utkarsh Tiwari References: [1] [6]<a class="moz-txt-link-freetext" href="https://bugs.sugarlabs.org/">https://bugs.sugarlabs.org/</a> _______________________________________________ Sugar-devel mailing list [<a class="moz-txt-link-abbreviated" href="mailto:7]Sugar-devel@lists.sugarlabs.org">7]Sugar-devel@lists.sugarlabs.org</a> [8]<a class="moz-txt-link-freetext" href="http://lists.sugarlabs.org/listinfo/sugar-devel">http://lists.sugarlabs.org/listinfo/sugar-devel</a> _______________________________________________ Sugar-devel mailing list [<a class="moz-txt-link-abbreviated" href="mailto:9]Sugar-devel@lists.sugarlabs.org">9]Sugar-devel@lists.sugarlabs.org</a> [10]<a class="moz-txt-link-freetext" href="http://lists.sugarlabs.org/listinfo/sugar-devel">http://lists.sugarlabs.org/listinfo/sugar-devel</a> -- James Cameron [11]<a class="moz-txt-link-freetext" href="http://quozl.netrek.org/">http://quozl.netrek.org/</a> _______________________________________________ Sugar-devel mailing list [<a class="moz-txt-link-abbreviated" href="mailto:12]Sugar-devel@lists.sugarlabs.org">12]Sugar-devel@lists.sugarlabs.org</a> [13]<a class="moz-txt-link-freetext" href="http://lists.sugarlabs.org/listinfo/sugar-devel">http://lists.sugarlabs.org/listinfo/sugar-devel</a> _______________________________________________ Sugar-devel mailing list [<a class="moz-txt-link-abbreviated" href="mailto:14]Sugar-devel@lists.sugarlabs.org">14]Sugar-devel@lists.sugarlabs.org</a> [15]<a class="moz-txt-link-freetext" href="http://lists.sugarlabs.org/listinfo/sugar-devel">http://lists.sugarlabs.org/listinfo/sugar-devel</a> References: [1] <a class="moz-txt-link-freetext" href="http://wiki.laptop.org/go/16.04.4">http://wiki.laptop.org/go/16.04.4</a> [2] <a class="moz-txt-link-freetext" href="http://wiki.laptop.org/go/NL3">http://wiki.laptop.org/go/NL3</a> [3] <a class="moz-txt-link-freetext" href="https://github.com/sugarlabs/sugar/commits/master">https://github.com/sugarlabs/sugar/commits/master</a> [4] <a class="moz-txt-link-freetext" href="http://wiki.sugarlabs.org/go/0.112#Fedora_18_on_OLPC_XO">http://wiki.sugarlabs.org/go/0.112#Fedora_18_on_OLPC_XO</a> [5] <a class="moz-txt-link-freetext" href="https://bugs.sugarlabs.org/">https://bugs.sugarlabs.org/</a> [6] <a class="moz-txt-link-freetext" href="https://bugs.sugarlabs.org/">https://bugs.sugarlabs.org/</a> [7] <a class="moz-txt-link-freetext" href="mailto:Sugar-devel@lists.sugarlabs.org">mailto:Sugar-devel@lists.sugarlabs.org</a> [8] <a class="moz-txt-link-freetext" href="http://lists.sugarlabs.org/listinfo/sugar-devel">http://lists.sugarlabs.org/listinfo/sugar-devel</a> [9] <a class="moz-txt-link-freetext" href="mailto:Sugar-devel@lists.sugarlabs.org">mailto:Sugar-devel@lists.sugarlabs.org</a> [10] <a class="moz-txt-link-freetext" href="http://lists.sugarlabs.org/listinfo/sugar-devel">http://lists.sugarlabs.org/listinfo/sugar-devel</a> [11] <a class="moz-txt-link-freetext" href="http://quozl.netrek.org/">http://quozl.netrek.org/</a> [12] <a class="moz-txt-link-freetext" href="mailto:Sugar-devel@lists.sugarlabs.org">mailto:Sugar-devel@lists.sugarlabs.org</a> [13] <a class="moz-txt-link-freetext" href="http://lists.sugarlabs.org/listinfo/sugar-devel">http://lists.sugarlabs.org/listinfo/sugar-devel</a> [14] <a class="moz-txt-link-freetext" href="mailto:Sugar-devel@lists.sugarlabs.org">mailto:Sugar-devel@lists.sugarlabs.org</a> [15] <a class="moz-txt-link-freetext" href="http://lists.sugarlabs.org/listinfo/sugar-devel">http://lists.sugarlabs.org/listinfo/sugar-devel</a> </pre> </blockquote> <pre wrap=""> </pre> <blockquote type="cite"> <pre wrap="">_______________________________________________ Sugar-devel mailing list <a class="moz-txt-link-abbreviated" href="mailto:Sugar-devel@lists.sugarlabs.org">Sugar-devel@lists.sugarlabs.org</a> <a class="moz-txt-link-freetext" href="http://lists.sugarlabs.org/listinfo/sugar-devel">http://lists.sugarlabs.org/listinfo/sugar-devel</a> </pre> </blockquote> <pre wrap=""> </pre> </blockquote> </body> </html>