[Sugar-devel] Issue tracking on Github?

[Dave Crossland]

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 :)


> As far as I know, SOAS does not offer an 'install' option.
>

Should it? :)


> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20160404/d08dca87/attachment.html>