[Sugar-devel] Issue tracking on Github?

[James Cameron]

On Mon, Apr 04, 2016 at 12:48:15AM -0400, Dave Crossland wrote:
> Hi Tony!
> 
> On 3 April 2016 at 02:02, Tony Anderson <tony_anderson at usa.net> wrote:
> 
>     You are proposing, appropriately, a new way to handle version
>     control for Sugar.
> 
> I'm not sure about that :) I didn't intend to :) 
>  
> 
>     There is documented procedure to add new activities or to update
>     activities on ASLO. This procedure is working with update
>     notifications in the ASLO mailing list. This process is
>     independent (and ignorant of) github. So your proposal is a
>     change to current practice.
> 
> I don't follow - ASLO indexes activities and distributes their ".xo"
> packages, but they are not developed on that site... So moving their
> source hosting to Github would not effect ASLO...? :) 
>  
> 
>     The separate tracking would be a byproduct of changing to a
>     github based procedure from our current practice
>     (https://bugs.sugarlabs.org/) In my experience all bugs/issues
>     are reported here whether against a specific Sugar activity (say
>     Etoys) or against a component of Sugar.
> 
> As I said in earlier emails, I think Github has handled
> organization-wide issue tracking appropriately. 
>  
> 
>     I am not sure whether Sugar is supported as a desktop by all GNU
>     machines.  In particular, 32-bit Ubuntu is not supported. Debian
>     dropped the Record activity because it does not use gstreamer1.0
>     or gtk3. This is one of the eight protected activities which are
>     considered essential to a running Sugar.
> 
> Thanks for sharing these details :) 

Lest you believe that, I'll correct.

Sugar is supported as a desktop on Fedora.  Fedora 23 has Sugar 0.106
now.  Fedora 24 will have Sugar 0.108, the way things are heading.
It's looking good.

Sugar is supported as a desktop on Ubuntu.  Ubuntu 15.10 has Sugar
0.106 now.  Ubuntu 16.04 will have Sugar 0.106, the way things are
heading.  It works great, I've just tested it now.

Sugar is partially supported as a desktop on Debian.  Debian stable
release does not have Sugar.  Debian testing release has Sugar 0.106.

Tony's reference to "32-bit Ubuntu is not supported" is a reframing
and misrepresentation of OLPC's effort to make a custom 64-bit Ubuntu
with Sugar for a device we are targeting.  We made that available for
testing, but the return on investment hasn't justified the effort.

An OLPC custom 32-bit Ubuntu works fine; it took me 15 minutes to
install a VM and then another 40 minutes to do a mass rebuild of the
OLPC packages of Sugar 0.108, and after installing them it was
indistinguishable from 64-bit Ubuntu.  I did this to get an idea of
the effort involved, and to have a 32-bit system ready for testing of
architecture dependent bugs.  I've no plans to release it unless a
customer orders it.

The Record activity will certainly drop off the list unless some
development occurs, as I've already mentioned in a previous post.

>     As far as I know, SOAS does not offer an 'install' option.
> 
> Should it? :) 

In my opinion, no, it doesn't need to, because SoaS is not intended
for installing.

To install Sugar on Fedora, install Fedora Workstation then select the
Sugar packages.  The process can be automated using Kickstart, a
feature of Fedora.

There's no install option.  However, it does install fine.  The Fedora
23 SoaS (with Sugar 0.106) can be installed by starting Terminal,
"sudo liveinst", and answering the usual installation questions.  The
Sugar Labs Wiki documentation is way out of date, and is more of a
disservice than useful now.

It would be really easy to add an icon that runs the install, but as
yet nobody has bothered.  It isn't something that OLPC needs to do,
since we don't use SoaS; we preinstall in the factory.

>     You are right about the issue of which activity versions support
>     which Sugar releases. This is complicated by the factor that
>     some ASLO entries have more recent versions stored as 'earlier
>     versions'. Someone needs to grab the handle and set up an ASLO
>     system that can identify which activities work with which
>     versions and make potentially multiple versions visible in ASLO
>     as necessary.
> 
>     During the recent GCI, Walter Bender and some of the
>     participants came up with a scheme which allows an activity with
>     a binary blob to identify the XO model and configure with the
>     appropriate blob at run-time. I suspect there are activities
>     which need this fix.
> 
> I hope there is an issue for this :D
> 
> --
> Cheers
> Dave

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