[Sugar-devel] Issue tracking on Github?

Dave Crossland dave at lab6.com
Mon Apr 4 00:35:00 EDT 2016

Hi Devin!

On 3 April 2016 at 21:07, Devin Ulibarri <devin at ulibarri.website> wrote:

> I have been following this thread. These are my two cents.

Thanks for speaking up - you say you don't have so much tech know-how, but
considering policy doesn't require it and I'm glad to discuss this with you

> If it were me, I would have opted to keep everything on a server within
Sugar Labs' community's control.

This is a very reasonable proposal - and I had considered proposing this
myself, before I proposed consolidating on Github, but I didn't explain
why, so this is a good moment to :)

> Here is why:
> 1. Control. The community would be able to do what they wish with their
> data. (the other benefits really come from this one)

Most of the data on Github servers, and all the data that is uploaded to
the servers by the community, is available to the community in full and
unrestricted (and raw) form via the Github API.

There is a software freedom problem with github.com, since it provides
proprietary javascript software to run on your browser; but for me this
software is pretty trivial and personally I don't mind it.

> 2. Avoid "Lock in". Probably, now we think "we have the code, we can
> pack our bags at any time we want", but as we use 3rd party services we
> are investing more and more--and would probably be reluctant to move if
> GitHub were to "go rogue" (advertisements, privacy problems, who knows
> what they will think of next problems). Instead, we would probably just
> adapt and adapt until--suddenly--the atmosphere became unbearable.

SourceForge.org is exactly the nightmare scenario you describe -
- and Github is widely admired in the floss community as an antithesis of
sourceforge. Another large host of libre-software projects, code.google.com,
was shut down in the last year, with tools provided to migrate to Github.

The nature of git and the github API is that migrating to another system is
easy enough, and while it is certainly possible that they could just turn
everything off and we'd lose data stored only on their servers, it seems
extremely unlikely to me that people of good will would do such a thing. I
expect that if and when Github is shut down, it will provide tools to

> 3. It occurs to me that, if we maintain an option to issue bug reports
> anonymously (or even under an pseudonym) that we would be protecting
> data of minors. I do not want to contribute much more to a world where
> minors must identify themselves and thus all they say and do on the
> internet at 13 yrs. old is available to people to see when they are 40
> yrs. old.

Github allows pseudonym accounts :)

So, why do I not recommend that Sugar is developed using infrastructure
that Sugar Labs operates with free software?

Well, after a couple weeks poking around Sugar Labs, my subjective
perspective is that the Sugar project is slowly drying up - sadly! :(

On the issue of issue tracking, James noted that we do not currently see
any bug reports on the existing issue tracker. This could be an indicator
of what I generally perceive, but actually I think this may be because all
new tickets are being held for moderation by Samuel Cantero; I'll email the
system list about this in a moment.

However, here are 2 graphs from
https://activities.sugarlabs.org/en-US/statistics that show a collapse in
the number of downloads of Activities from ASLO, falling by 90% over the
last 3 years:

[image: Inline images 2][image: Inline images 1]


Samson prompted me to search for these graphs when, in
http://lists.sugarlabs.org/archive/sugar-devel/2016-January/051258.html ,
he said that "weekly downloads is falling like the price of crude oil" (lol

So I think it is urgent that the Sugar community begins to grow again.

The Sugar project doesn't exist in a vacuum, it exists in a social context
of the wider floss community, and that community is - for now -
overwhelmingly using Github for project hosting and issue tracker.

I think that using the same infrastructure as the majority of the rest of
the floss community is an effective strategy to meet that goal; and I think
that using our own infrastructure will make the project insular and deter

> This all being said, I have no technical know-how to fix the broken
> system. And the reason I use GitHub is because that was the system that
> was introduced to me. If the software on the Sugar server gets fixed, I
> will happily participate in that one.

Well, this is sort of the point. The software on the sugar server is
functioning fine (modulo a moderation queue misconfiguration :) and there
was already an effort to move to Github.

> Well, 4. If we can fix the problem and try to improve whatever software
> libre we are running server-side, we will be contributing to the
> advancement of software libre tools for the entire community (even if we
> are just filing bug reports, etc).

Sugar is in the business of developing educational application-level
software, and not wifi driver firmware software, nor software project
hosting software.

I acknowledge that it is somewhat contradictory to advocate for software
freedom as a general principle, yet use proprietary software. I've been a
member of the floss community for about 17 years now, and myself and almost
all software freedom advocates that I've met all around the world do
embrace that contradiction to some extent.

Today there are a very few who use only X60/X200 laptops with libreboot and
zero proprietary software installed, and browse the web with GNU IceCat so
that no proprietary javascript programs are executed; they either work at
FSF, Conservancy, or develop libreboot and sell such laptops :) I would be
happy to hear otherwise, but I suspect that no-one contributing to Sugar
uses only libre software.

I admit that I am right now typing this email into proprietary javascript
program - GMail - on a Mac that runs Mac OS X. I explain this by saying
that I have various needs, including for freedom, but also for convenience,
community, and focus; and I'm willing to engage in strategies that meet
some needs less than 100% in order to meet all needs somewhat.

I recommend this approach of considering the trade-offs to Sugar Labs, and
being willing to compromise a little on software freedom where it matter
less to gain other important capabilities. I offer that this is similar to
how the XO laptops require proprietary firmware to use wifi.

If the need for freedom and autonomy in project hosting is strong, and
alternatives to Github are sought, I recommend http://www.fossil-scm.org :)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20160404/66ce7ec5/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2016-04-02 at 15.20.40.png
Type: image/png
Size: 77445 bytes
Desc: not available
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20160404/66ce7ec5/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2016-04-02 at 15.20.47.png
Type: image/png
Size: 72447 bytes
Desc: not available
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20160404/66ce7ec5/attachment-0003.png>

More information about the Sugar-devel mailing list