[Sugar-devel] Issue tracking on Github?

[Walter Bender]

On Mon, Apr 4, 2016 at 10:08 AM, Dave Crossland <dave at lab6.com> wrote:

>
> Hi!
>
> On 4 April 2016 at 00:50, Devin Ulibarri <devin at ulibarri.website> wrote:
>
>> On 04/04/2016 12:35 AM, Dave Crossland wrote:
>> >     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 <http://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.
>>
>> I was more concerned with the amount of latitude that the services
>> SugarLabs.
>>
>> For example (to make point more clear), if you had your own server would
>> you rather download and use Wordpress software? Or use a WordPress as a
>> service hosted on someone else's computer?
>
>
> For myself, I haven't run my own servers in a long time. They just got
> hacked, and it stopped being fun and became labor that I wasn't being paid
> to perform, so in 2006 I stopped and move to a "shared hosting" provider (
> dreamhost.com) and installed WordPress there. And I still got hacked at
> the wp database level.
>

FWIW, we have had a very hard time keeping hackers out of our trac system.
Despite extreme measures, SCG still has to manually remove hacked accounts.
IMHO, it is not worth the effort to maintain. His limited time would be
much better spent on infrastructure unique to Sugar Labs, such as
maintaining the customizations we have made to the activity portal.

>
> So today for hosting and serving all websites that I administer, I prefer
> to use 'static site generator' blog/website cms, and specifically jeykll on
> pages.github.com; the jeykll software that runs on Github's servers is
> available as public libre software so I can replicate the hosting
> environment, and the 'pull request' collaboration model is great.
>
>
>> >     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
>> > -
>> http://arstechnica.com/information-technology/2015/05/sourceforge-grabs-gimp-for-windows-account-wraps-installer-in-bundle-pushing-adware/
>> > - and Github is widely admired in the floss community as an antithesis
>> > of sourceforge. Another large host of libre-software projects,
>> > code.google.com <http://code.google.com>, was shut down in the last
>> > year, with tools provided to migrate to Github.
>>
>> Yes, I had SourceForge in mind...
>>
>> > 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 migrate.
>>
>> Migrating code is easy, but it is also valuable to have the data of the
>> issues as well when possible. (one could download pages as HTML, but
>> that would be laborious)
>
>
> The Github API provides the data of the issues; there are several 3rd
> party issue tracking UIs that build a proprietary software business on top
> of it.
>
> https://developer.github.com/v3
>
> Eg https://huboard.com https://www.zenhub.io https://waffle.io
> https://codetree.com
>
>
>> >     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 :)
>>
>> Yes, but we are still asking kids to sign up with a service that they
>> may have otherwise had no interest in signing up for.
>
>
> I am proposing to ask kids to sign up with Github because I strongly
> expect that they have a wider interest in signing up for it - because
> almost all other libre software projects that they will interact with are
> currently on the service.
>
>
>> "Welcome to
>> SugarLabs, now sign up for GitHub". So GitHub gets the data for the
>> student's email (I cannot remember if real name is required, but it
>> almost does not matter b/c they can change their policy at any time)
>
>
> Github does not require real names.
>
> If we are concerned about educating children about maintaining
> pseudonymity, we can recommend using http://mailinator.com or a
> github-specific disposable email account; but I don't really understand
> your concern about Github having a student's email. I observe a lot of
> young people with emails like DaveCrosslandRocks at gmail.com, so inevitably
> as they grow up they will need to get a more formal email.
>
>
>> >     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.
>>
>> I am confused. I thought something was not / is not working...
>>
>
> What is not working is not the functioning of the software, but the
> incoherence between having issues in one system (that is obscure) and code
> in another system - the by-far-most-widely-used libre software development
> service.
>
>
>> The reason I am using GitHub and not Sugar Server is because that was
>> the solution introduced to me.
>
>
> :)
>
>
>> >     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.
>>
>> Just like we would appreciate it if people used Sugar software and sent
>> in bug reports when they ran into problems, I know that developers of
>> server-side libre git solutions would appreciate having more members of
>> the community try their stuff and send in our thoughts and other
>> contributions. ...it is encouraging for them, at the very least.
>>
>
> No doubt :)
>
> Well, we have 2 proposals for consolidation, one to move totally to Github
> and one to move totally away from Github. How to decide? :)
>
> --
> Cheers
> Dave
>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>


-- 
Walter Bender
Sugar Labs
http://www.sugarlabs.org
<http://www.sugarlabs.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20160404/94b4135c/attachment-0001.html>