Re: [Sugar-devel] Issue tracking on Github?

[Dave Crossland]

On 6 June 2016 at 19:30, Devin  wrote:
> the published code is not very mature so it does not yet matter if it has a
> license

Right; if it _is_ code (which it probably isn't) then it is probably
not very useful for anything, and if you do want a license for it, you
can ask for one, and you will very likely get one :)
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Issue tracking on Github?

[Dave Crossland]

I am certainly more mindful of this issue; I came across
https://github.com/mortenjust/cleartext-mac/ today and saw there was
no license, and after my bleeting the developed added GPLv3 :)
https://github.com/mortenjust/cleartext-mac/issues/3
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Issue tracking on Github?

[Devin]

On 06/06/2016 07:08 PM, Dave Crossland wrote:
> First, I think there must be a large fraction of all github repos that
> have less than 10 commits with almost nothing in them and are
> essentially worthless. If those don't have a LICENSE file, I don't
> mind :)

I think this way of looking at the issue is wrongheaded. However, my
solution to this problem requires a change to GitHub's entire model... :-P

I always thought it strange that public repos is the default. I do not
think it makes sense to have beginners have their repos be public by
default, for example. Of course someone publishing their first repo
doesn't have a license--they do not know what they are doing (coding,
licensing, everything). So, I would imagine that it would help beginners
if they could start with private repos--maybe they just share with their
friends and teachers/mentors. Then, when things start picking up speed,
they choose to go public (and at that point are required to choose a
license).

"Open Source" confuses "public" and "private" in this way. (Google, for
GSoC for example, states that Open Source means that all development
happen publicly--out in the open). "Free software" makes "public" and
"private" a separate matter--as long as you have the four freedoms, it
is free/libre software.

The GNU project, for example, was done privately at first. Only when the
code was made public (i.e. distributed) did the license really matter.
Before the code is distributed--when it is still private--it is neither
here nor their license-wise (software freedom-wise). Dave, what I think
you are trying to say is that the published code is not very mature so
it does not yet matter if it has a license. Since private code doesn't
need a license either, I would propose that GitHub allow noobs to have
private repos... (As I said before, I understand that this would be a
significant change to their business model)

...but then again I do not represent GitHub. The best I could do is
share my opinion with them.

Thanks for the conversation! Love it! :-)
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Issue tracking on Github?

[Dave Crossland]

On 6 June 2016 at 16:16, Devin  wrote:
> (This is long, gnarly thread, but I just like to think about this sort of
> stuff, what can I say...)

:D

To say Github is a failed state seems rather absurd to me, compared to
the other 2 large code hosting sites, SourceForce and Google Code
Hosting ;)

I think its a great metaphor, but I'm not convinced about the data
collection used for the graph.

First, I think there must be a large fraction of all github repos that
have less than 10 commits with almost nothing in them and are
essentially worthless. If those don't have a LICENSE file, I don't
mind :)

Second, I think often the license is indicated in a way that the
search for licenses hasn't accounted for because it might be ambiguous
to a machine but unambiguous to a human.

For example, there are 25 repos listed on https://github.com/trending
and of those 12 did not have a file named "LICENSE*" but 9 of those 12
stated a license in the README (usually at the very end)

Of those 3 without a license file or statement in README, 2 were repos
with a single README used to collaboratively collect links on a topic:

https://github.com/vic317yeh/One-Click-to-Be-Pro

https://github.com/terryum/awesome-deep-learning-papers

Only 1 was a software package: https://github.com/WuXiaolong/AndroidUtils

However, it is only 1,300 lines (mostly XML configuration, from what I
can tell) and is 17 days old; my issue to ask about the license is the
first one filed: https://github.com/WuXiaolong/AndroidUtils/issues/1

In using Github over the last 6 years, I can't say that I have come
across many repos that didn't have licenses clearly indicated; I have
come across a handful, and filed an issue asking for a license and it
was quickly added as a forgetful oversight.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Issue tracking on Github?

[Devin]

On 06/06/2016 06:34 PM, Walter Bender wrote:
>> This is interesting: http://250bpm.com/blog:82
>> >
>> > Not sure I buy into the failed-state hypothesis, but it is interesting
> nonetheless.

The person who sent the link was not certain the information is entirely
correct, so I do think it would be important (for someone) to look into
and not trust this one figure completely.

Devin
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Issue tracking on Github?

[Walter Bender]

On Mon, Jun 6, 2016 at 6:16 PM, Devin  wrote:

> (This is long, gnarly thread, but I just like to think about this sort of
> stuff, what can I say...)
>
> On 05/27/2016 09:05 AM, Walter Bender wrote:
>
> This has been the topic of a lot of discussion on the FOSS foundation list
> of late. I think there is a movement afoot to push them towards a default
> FOSS license.
>
>
> This is interesting: http://250bpm.com/blog:82
>
> Not sure I buy into the failed-state hypothesis, but it is interesting
nonetheless. I had proposed to Dan Ariely years ago that he try to design
some experiments to try to tease out under what circumstances people
participate in open culture/software libre projects. Would be interesting
to get some data about what is really motivating folks.

Meanwhile, we can/do choose to only accept FOSS-licensed contributions, so
it is a bit moot (unless requiring a license is somehow deterring
contributions).

-walter


> Shows a graph of decline of software published on GitHub with any license
> at all.
>
> I think a repo needs to make its users choose a license--any license--but
> should not publish publicly until a license has been chosen.
>
> The "default" is a suggestion for convenience. Defaults do have
> implications for what choices people make, but right now the "default" is
> "no license at all" (ambiguous to its community and legally proprietary).
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>


-- 
Walter Bender
Sugar Labs
http://www.sugarlabs.org

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Issue tracking on Github?

[Devin]

(This is long, gnarly thread, but I just like to think about this sort
of stuff, what can I say...)

On 05/27/2016 09:05 AM, Walter Bender wrote:
> This has been the topic of a lot of discussion on the FOSS foundation list
> of late. I think there is a movement afoot to push them towards a default
> FOSS license.

This is interesting: http://250bpm.com/blog:82

Shows a graph of decline of software published on GitHub with any
license at all.

I think a repo needs to make its users choose a license--any
license--but should not publish publicly until a license has been chosen.

The "default" is a suggestion for convenience. Defaults do have
implications for what choices people make, but right now the "default"
is "no license at all" (ambiguous to its community and legally proprietary).
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Issue tracking on Github?

[Dave Crossland]

Hi

On 27 May 2016 at 11:16, Devin Ulibarri  wrote:

> On 05/27/2016 09:03 AM, Dave Crossland wrote:
> >
> > On 27 May 2016 at 08:59, Devin Ulibarri  > > wrote:
> >
> > Notice from the ethics article that one big deal with GitHub is it
> > allows developers to upload code without a license (thus being
> > proprietary by default, even though we can all see the code).
> >
> >
> > I don't think a default libre license would be wise; for a start, which
> > one?
>
> I think the idea is to have options that someone may choose from (like
> the way media goblin lists options for copyright licenses when you
> upload a file). Each option could (should) have a description of the
> license and links to the original license text.
>

They already do this; they recently added GPLv3 to the list, although they
refuse to add the SIL Open Font License because fonts projects are such a
tiny fraction of all projects :(


> And, yes, MediaGoblin does allow for "all rights reserved" or "custom"
> license, so I imagine that GitHub could make some accordances for this.


Does MediaGoblin apply a license by default, if you don't select one?


> > Licensing is serious stuff and I think its self-defeating for the
> movement to make people less conscious of it by offering easy defaults :)
>
> Licensing **really is** serious stuff and that is exactly why people
> need to choose their license when they post their work publicly.
>
> Having no license, if someone accidentally downloads and uses the code
> without express permission, since the default US copyright law would
> have it "All Rights Reserved" it puts the people who have access to the
> code at risk of possible litigation (i.e. they could be sued later for
> using the code).


There's potential estoppel defences, but yes, I agree, that is bad.

-- 
Cheers
Dave
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Issue tracking on Github?

[Devin Ulibarri]

On 05/27/2016 11:16 AM, Devin Ulibarri wrote:
> Having no license, if someone accidentally downloads and uses the code
> without express permission, since the default US copyright law would
> have it "All Rights Reserved" it puts the people who have access to the
> code at risk of possible litigation (i.e. they could be sued later for
> using the code).

Fortunately, this story ends with a happy ending (as happy as licensing
stories can get)...

I made this issue to ask developer to add license to their code.

https://github.com/arzynik/cheryl/issues/30

Good news is they chose free license (MIT).

Bad news is it took more than 6 months for them to do it (added three
days ago and maybe only because I asked).
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Issue tracking on Github?

[Devin Ulibarri]

On 05/27/2016 09:03 AM, Dave Crossland wrote:
> 
> On 27 May 2016 at 08:59, Devin Ulibarri  > wrote:
> 
> Notice from the ethics article that one big deal with GitHub is it
> allows developers to upload code without a license (thus being
> proprietary by default, even though we can all see the code).
> 
> 
> I don't think a default libre license would be wise; for a start, which
> one? 

I think the idea is to have options that someone may choose from (like
the way media goblin lists options for copyright licenses when you
upload a file). Each option could (should) have a description of the
license and links to the original license text.

And, yes, MediaGoblin does allow for "all rights reserved" or "custom"
license, so I imagine that GitHub could make some accordances for this.

> Licensing is serious stuff and I think its self-defeating for the movement to 
> make people less conscious of it by offering easy defaults :) 

Licensing **really is** serious stuff and that is exactly why people
need to choose their license when they post their work publicly.

Having no license, if someone accidentally downloads and uses the code
without express permission, since the default US copyright law would
have it "All Rights Reserved" it puts the people who have access to the
code at risk of possible litigation (i.e. they could be sued later for
using the code).

Devin
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Issue tracking on Github?

[Dave Crossland]

On 27 May 2016 at 09:05, Walter Bender  wrote:

> This has been the topic of a lot of discussion on the FOSS foundation list
> of late. I think there is a movement afoot to push them towards a default
> FOSS license.
>

Which list is that?
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Issue tracking on Github?

[Walter Bender]

On Fri, May 27, 2016 at 8:59 AM, Devin Ulibarri 
wrote:

> On 05/27/2016 08:55 AM, Dave Crossland wrote:
> > I think its pretty clear that Github's business model _depends_ on it
> > hosting the world's libre licensed code: That's how they get developers
> > into their conversion funnel.
>
> Notice from the ethics article that one big deal with GitHub is it
> allows developers to upload code without a license (thus being
> proprietary by default, even though we can all see the code).
>
> As a start, I think we should push on GitHub to discourage this practice.
>

This has been the topic of a lot of discussion on the FOSS foundation list
of late. I think there is a movement afoot to push them towards a default
FOSS license.

-walter

>
> Devin
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>



-- 
Walter Bender
Sugar Labs
http://www.sugarlabs.org

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Issue tracking on Github?

[Dave Crossland]

Hi

On 27 May 2016 at 08:59, Devin Ulibarri  wrote:

> Notice from the ethics article that one big deal with GitHub is it
> allows developers to upload code without a license (thus being
> proprietary by default, even though we can all see the code).
>

I don't think a default libre license would be wise; for a start, which
one?

I've seen PLENTY of projects intend to be licensed as X but accidentally
adding license Y to the repo and then just updating the file, so the old
license is there in the git history.

As a start, I think we should push on GitHub to discourage this practice.
>

Licensing is serious stuff and I think its self-defeating for the movement
to make people less conscious of it by offering easy defaults :)

-- 
Cheers
Dave
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Issue tracking on Github?

[Devin Ulibarri]

On 05/27/2016 08:55 AM, Dave Crossland wrote:
> I think its pretty clear that Github's business model _depends_ on it
> hosting the world's libre licensed code: That's how they get developers
> into their conversion funnel. 

Notice from the ethics article that one big deal with GitHub is it
allows developers to upload code without a license (thus being
proprietary by default, even though we can all see the code).

As a start, I think we should push on GitHub to discourage this practice.

Devin
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Issue tracking on Github?

[Dave Crossland]

Hi

On 27 May 2016 at 08:29, Devin Ulibarri  wrote:

> (I found this in my drafts folder and am sending it out. I know a
> decision was made about this, but am sending for continued reference.)


Thank you! :)


>
> On 05/16/2016 11:13 PM, Dave Crossland wrote:
> > Hi
> >
> > Does anyone want to discuss any more objections with me, or can I
> > migrate the issue tracking to Github now? :)
>
> There has been some recent talk about this on various channels. I don't
> know if any of this information will change anything, but I think it is
> worth looking at and considering.
>
>
> http://www.fsf.org/blogs/community/ethics-in-ethics-out-promote-user-respecting-software-development-platforms


If someone wants to set up a container for gitlab and mirror the github
org, then we could flip the mirror and have github be a downstream mirror
of the gitlab. But who will do this?


> (Found the following while trying to find the above article.)
>
> http://www.wired.com/2015/06/problem-putting-worlds-code-github/


The article ends with,

The question is ultimately whether GitHub will find ways to stay true to
its ideals while generating returns—or wind up the stuff of legend.


I think its pretty clear that Github's business model _depends_ on it
hosting the world's libre licensed code: That's how they get developers
into their conversion funnel.

-- 
Cheers
Dave
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Issue tracking on Github?

[Devin Ulibarri]

(I found this in my drafts folder and am sending it out. I know a
decision was made about this, but am sending for continued reference.)

On 05/16/2016 11:13 PM, Dave Crossland wrote:
> Hi
> 
> Does anyone want to discuss any more objections with me, or can I
> migrate the issue tracking to Github now? :) 

There has been some recent talk about this on various channels. I don't
know if any of this information will change anything, but I think it is
worth looking at and considering.

http://www.fsf.org/blogs/community/ethics-in-ethics-out-promote-user-respecting-software-development-platforms

(Found the following while trying to find the above article.)

http://www.wired.com/2015/06/problem-putting-worlds-code-github/

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Issue tracking on Github?

[Dave Crossland]

On 18 May 2016 at 11:59, Bert Freudenberg  wrote:

> On 18.05.2016, at 17:01, Dave Crossland  wrote:
>
> On 18 May 2016 at 10:54, Bert Freudenberg  wrote:
>
>> On 18.05.2016, at 16:26, Dave Crossland  wrote:
>>
>>
>> Hi
>>
>> On 18 May 2016 at 09:57, Tony Anderson  wrote:
>>
>>> Its an educational project. An example is
>>> https://github.com/ezequielpereira/Bridge. This version of the
>>> Bridge-activity was developed as part of GCI.
>>> The zip downloaded from github is named Bridge-master.zip. I copied the
>>> zip to an XO-1.75, unzipped, and ran setup.py dist_xo. The result was a
>>> proper xo bundle which installed and ran.
>>>
>>
>> Sounds good :)
>>
>>
>>> However, it failed to start: import error lib/box2d_32/_Box2D.so.
>>>
>>
>> Is that error a bug in the program?
>>
>>
>> More likely an intel / arm problem. The XO-1.75 needs ARMv7 binaries,
>> while older XOs used x86. The activity bundle would have to include .so
>> files for each supported architecture. I don’t think we ever extended the
>> bundle structure to properly handle multi-arch, it was designed for
>> platform-independent code like Python.
>>
>
> Okay cool :)
>
> Can the bundle structure deal with this in an ad-hoc way, or does it need
> changes to the Sugar Desktop platform itself?
>
>
> The bundle can have arbitrary library folders, but the activity would need
> to implement selecting the right binary for the current architecture.
>

Awesome!

I filed https://github.com/sugarlabs/sugar-docs/issues/87 to help raise
awareness of this :)

-- 
Cheers
Dave
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Issue tracking on Github?

[Bert Freudenberg]

On 18.05.2016, at 17:01, Dave Crossland  wrote:
> On 18 May 2016 at 10:54, Bert Freudenberg  > wrote:
> On 18.05.2016, at 16:26, Dave Crossland  > wrote:
>> 
>> Hi
>> 
>> On 18 May 2016 at 09:57, Tony Anderson > > wrote:
>> Its an educational project. An example is 
>> https://github.com/ezequielpereira/Bridge 
>> . This version of the 
>> Bridge-activity was developed as part of GCI. 
>> The zip downloaded from github is named Bridge-master.zip. I copied the zip 
>> to an XO-1.75, unzipped, and ran setup.py dist_xo. The result was a 
>> proper xo bundle which installed and ran. 
>> 
>> Sounds good :)
>>  
>> However, it failed to start: import error lib/box2d_32/_Box2D.so.
>> 
>> Is that error a bug in the program?
> 
> More likely an intel / arm problem. The XO-1.75 needs ARMv7 binaries, while 
> older XOs used x86. The activity bundle would have to include .so files for 
> each supported architecture. I don’t think we ever extended the bundle 
> structure to properly handle multi-arch, it was designed for 
> platform-independent code like Python.
> 
> Okay cool :)
> 
> Can the bundle structure deal with this in an ad-hoc way, or does it need 
> changes to the Sugar Desktop platform itself? 

The bundle can have arbitrary library folders, but the activity would need to 
implement selecting the right binary for the current architecture.

- Bert -



smime.p7s
Description: S/MIME cryptographic signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Issue tracking on Github?

[Dave Crossland]

On 18 May 2016 at 10:54, Bert Freudenberg  wrote:

> On 18.05.2016, at 16:26, Dave Crossland  wrote:
>
>
> Hi
>
> On 18 May 2016 at 09:57, Tony Anderson  wrote:
>
>> Its an educational project. An example is
>> https://github.com/ezequielpereira/Bridge. This version of the
>> Bridge-activity was developed as part of GCI.
>> The zip downloaded from github is named Bridge-master.zip. I copied the
>> zip to an XO-1.75, unzipped, and ran setup.py dist_xo. The result was a
>> proper xo bundle which installed and ran.
>>
>
> Sounds good :)
>
>
>> However, it failed to start: import error lib/box2d_32/_Box2D.so.
>>
>
> Is that error a bug in the program?
>
>
> More likely an intel / arm problem. The XO-1.75 needs ARMv7 binaries,
> while older XOs used x86. The activity bundle would have to include .so
> files for each supported architecture. I don’t think we ever extended the
> bundle structure to properly handle multi-arch, it was designed for
> platform-independent code like Python.
>

Okay cool :)

Can the bundle structure deal with this in an ad-hoc way, or does it need
changes to the Sugar Desktop platform itself?

-- 
Cheers
Dave
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Issue tracking on Github?

[Bert Freudenberg]

On 18.05.2016, at 16:26, Dave Crossland  wrote:
> 
> Hi
> 
> On 18 May 2016 at 09:57, Tony Anderson  > wrote:
> Its an educational project. An example is 
> https://github.com/ezequielpereira/Bridge 
> . This version of the 
> Bridge-activity was developed as part of GCI. 
> The zip downloaded from github is named Bridge-master.zip. I copied the zip 
> to an XO-1.75, unzipped, and ran setup.py dist_xo. The result was a 
> proper xo bundle which installed and ran.
> 
> Sounds good :)
>  
> However, it failed to start: import error lib/box2d_32/_Box2D.so.
> 
> Is that error a bug in the program?

More likely an intel / arm problem. The XO-1.75 needs ARMv7 binaries, while 
older XOs used x86. The activity bundle would have to include .so files for 
each supported architecture. I don’t think we ever extended the bundle 
structure to properly handle multi-arch, it was designed for 
platform-independent code like Python.

- Bert -





smime.p7s
Description: S/MIME cryptographic signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Issue tracking on Github?

[Dave Crossland]

Hi

On 18 May 2016 at 09:57, Tony Anderson  wrote:

> Its an educational project. An example is
> https://github.com/ezequielpereira/Bridge. This version of the
> Bridge-activity was developed as part of GCI.
> The zip downloaded from github is named Bridge-master.zip. I copied the
> zip to an XO-1.75, unzipped, and ran setup.py dist_xo. The result was a
> proper xo bundle which installed and ran.
>

Sounds good :)


> However, it failed to start: import error lib/box2d_32/_Box2D.so.
>

Is that error a bug in the program?


> So setup.py solves the problem of the folder name. However, it does
> suggest that we will need to upload xo bundles through a two step process
> of
> downloading the zip and using it to create the bundle to be uploaded to
> ASLO.
>

I understand that :)

https://docs.travis-ci.com/user/deployment/ is a way to automate that
process.


> On ASLO, this activity is shown as working on versions 0.82-0.104. This is
> clearly not correct. I found in uploading helloweb that this range is the
> default
>
value. It is possible to set the lower end (e.g. 0.100 for
> sugar-web-activities) but the upper end is 0.104 (0.106, 0.108 have not
> been added to the widget).
>

Who has admin access to ASLO to fix this?


> This import error raises again the issue that some dependencies will be
> changed based on XO model and on 32 or 64 bit architechture. During GCI,
> Walter set up a platform variable that activities can test to determine the
> environment. This will become increasingly important to developers.
>

I agree this will be important, so I filed
https://github.com/sugarlabs/sugar-docs/issues/87

-- 
Cheers
Dave
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Issue tracking on Github?

[Tony Anderson]

Hi, Dave

Its an educational project. An example is 
https://github.com/ezequielpereira/Bridge. This version of the 
Bridge-activity was developed as part of GCI.
The zip downloaded from github is named Bridge-master.zip. I copied the 
zip to an XO-1.75, unzipped, and ran setup.py dist_xo. The result was a
proper xo bundle which installed and ran. However, it failed to start: 
import error lib/box2d_32/_Box2D.so.


So setup.py solves the problem of the folder name. However, it does 
suggest that we will need to upload xo bundles through a two step 
process of
downloading the zip and using it to create the bundle to be uploaded to 
ASLO.


On ASLO, this activity is shown as working on versions 0.82-0.104. This 
is clearly not correct. I found in uploading helloweb that this range is 
the default
value. It is possible to set the lower end (e.g. 0.100 for 
sugar-web-activities) but the upper end is 0.104 (0.106, 0.108 have not 
been added to the widget).


This import error raises again the issue that some dependencies will be 
changed based on XO model and on 32 or 64 bit architechture. During GCI, 
Walter set up a platform variable that activities can test to determine 
the environment. This will become increasingly important to developers.


Tony

On 05/18/2016 02:42 PM, Dave Crossland wrote:


On 18 May 2016 at 08:18, Tony Anderson > wrote:


As I understand it, what you are trying to do is make github the
place where Sugar activities are kept.


The source code for activities has traditionally lived on 
http://git.sugarlabs.org/projects but this is going to be shut down 
this year, because the software is no longer maintained and each week 
it becomes a bigger and bigger liability; meanwhile many activities 
have already naturally found a home to live in on Github.


Currently, ASLO provides for upload of an
activity (new or new version) as an xo bundle from the user's file
system.


This should not be a manual process in 2016 :)

What would be needed is a way to release an xo bundle from the
github repository.


https://docs.travis-ci.com/user/deployment/

Experience in the last GCI showed that the way Sugar activities
are stored in GitHub is not compatible with the requirements of an
xo bundle.
For example, a Sugar activity must have a top-level folder with
the name x.activity.


Please help me locate the discussion about this, the assertion Github 
releases can't work with this requirement seems totally incorrect to me.


By custom, the version is shown in the xo file name (e.g.
helloweb-3.xo) and should match the version number given in
activity.info . However, this requires an
act by the developer and is not automatic.


I am very confident I can automate this.

So I think some programming is required to release activities from
github to ASLO and to update the ASLO developer hub to conform to
the new requirements.


Sure! Its going to be great! :D

--
Cheers
Dave


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Issue tracking on Github?

[Tony Anderson]

Hi, Dave

As I understand it, what you are trying to do is make github the place 
where Sugar activities are kept. Currently, ASLO provides for upload of an
activity (new or new version) as an xo bundle from the user's file 
system. What would be needed is a way to release an xo bundle from the 
github
repository. Experience in the last GCI showed that the way Sugar 
activities are stored in GitHub is not compatible with the requirements 
of an xo bundle.
For example, a Sugar activity must have a top-level folder with the name 
x.activity.


By custom, the version is shown in the xo file name (e.g. helloweb-3.xo) 
and should match the version number given in activity.info. However, 
this requires an act by the developer and is not automatic.


So I think some programming is required to release activities from 
github to ASLO and to update the ASLO developer hub to conform to the 
new requirements.


Tony

On 05/18/2016 01:52 PM, Dave Crossland wrote:

Hi

On 18 May 2016 at 04:29, Tony Anderson > wrote:


Sugar activities from the beginning identified versions by version
number. For some activities we have tens of versions in ASLO.
Switching version control from a version number to git branches
may be non-trivial. It would certainly be helpful to view changes
to activities over time.


There are commits where the version is marked in the activity's commit 
history, and its easy to tag those commits as releases; then Github 
automatically shows them in a release timeline page. Automating the 
release process (ie, making the .xo bundle and uploading it to the 
release page as a binary attachment) is also straightforward with 
Travis CI.


I still believe it is far more important to have a link from the
ASLO entry for an activity to its github repo than to include the
link in activity.info .


Great idea :)

https://wiki.sugarlabs.org/index.php?title=Vision_proposal_2016=revision=98736=98696 



--
Cheers
Dave


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Issue tracking on Github?

[Dave Crossland]

Hi

On 18 May 2016 at 04:29, Tony Anderson  wrote:

> Sugar activities from the beginning identified versions by version number.
> For some activities we have tens of versions in ASLO. Switching version
> control from a version number to git branches may be non-trivial. It would
> certainly be helpful to view changes to activities over time.
>

There are commits where the version is marked in the activity's commit
history, and its easy to tag those commits as releases; then Github
automatically shows them in a release timeline page. Automating the release
process (ie, making the .xo bundle and uploading it to the release page as
a binary attachment) is also straightforward with Travis CI.


> I still believe it is far more important to have a link from the ASLO
> entry for an activity to its github repo than to include the link in
> activity.info.
>

Great idea :)

https://wiki.sugarlabs.org/index.php?title=Vision_proposal_2016=revision=98736=98696


-- 
Cheers
Dave
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Issue tracking on Github?

[Tony Anderson]

Sugar activities from the beginning identified versions by version 
number. For some activities we have tens of versions in ASLO. Switching 
version control from a version number to git branches may be 
non-trivial. It would certainly be helpful to view changes to activities 
over time.


I still believe it is far more important to have a link from the ASLO 
entry for an activity to its github repo than to include the link in 
activity.info.


Tony

On 05/17/2016 07:37 PM, Walter Bender wrote:


On Tue, May 17, 2016 at 12:35 PM, Dave Crossland > wrote:



On 17 May 2016 at 09:46, Walter Bender > wrote:

we need to send out a clear description of what is expected of
App developers ("transfer" their repos to sugarlabs) and how
to manage issues once the switch-over has occurred.


https://wiki.sugarlabs.org/go/Infrastructure_Team/Migrating_Bugs_to_GitHub


Great. Thx.



--
Walter Bender
Sugar Labs
http://www.sugarlabs.org



___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Issue tracking on Github?

[Walter Bender]

On Tue, May 17, 2016 at 12:35 PM, Dave Crossland  wrote:

>
> On 17 May 2016 at 09:46, Walter Bender  wrote:
>
>> we need to send out a clear description of what is expected of App
>> developers ("transfer" their repos to sugarlabs) and how to manage issues
>> once the switch-over has occurred.
>
>
> https://wiki.sugarlabs.org/go/Infrastructure_Team/Migrating_Bugs_to_GitHub
>

Great. Thx.




-- 
Walter Bender
Sugar Labs
http://www.sugarlabs.org

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Issue tracking on Github?

[Dave Crossland]

On 17 May 2016 at 11:44, Walter Bender  wrote:

>
> On Tue, May 17, 2016 at 11:03 AM, Dave Crossland  wrote:
>
>>
>> On 3 April 2016 at 20:36, James Cameron  wrote:
>>
>>> >
>>> > Is wiki.sugarlabs.org used for tracking release engineering work?
>>>
>>> I'm not the release engineer for Sugar, sorry.
>>
>>
>> Who will manage the 0.110 release?
>>
>> https://wiki.sugarlabs.org/go/Development_Team/Contacts seems stale :/
>>
>
> AFAIK, Martin is still the release manager.
>

Okay cool, I updated the wiki page.

Martin, what month do you expect to start and end the 0.110 release
process? :)
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Issue tracking on Github?

[Dave Crossland]

On 17 May 2016 at 09:46, Walter Bender  wrote:

> we need to send out a clear description of what is expected of App
> developers ("transfer" their repos to sugarlabs) and how to manage issues
> once the switch-over has occurred.


https://wiki.sugarlabs.org/go/Infrastructure_Team/Migrating_Bugs_to_GitHub
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Issue tracking on Github?

[Walter Bender]

AFAIK, Martin is still the release manager.

-walter

On Tue, May 17, 2016 at 11:03 AM, Dave Crossland  wrote:

>
> On 3 April 2016 at 20:36, James Cameron  wrote:
>
>> >
>> > Is wiki.sugarlabs.org used for tracking release engineering work?
>>
>> I'm not the release engineer for Sugar, sorry.
>
>
> Who will manage the 0.110 release?
>
> https://wiki.sugarlabs.org/go/Development_Team/Contacts seems stale :/
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>


-- 
Walter Bender
Sugar Labs
http://www.sugarlabs.org

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Issue tracking on Github?

[Dave Crossland]

On 3 April 2016 at 20:36, James Cameron  wrote:

> >
> > Is wiki.sugarlabs.org used for tracking release engineering work?
>
> I'm not the release engineer for Sugar, sorry.


Who will manage the 0.110 release?

https://wiki.sugarlabs.org/go/Development_Team/Contacts seems stale :/
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Issue tracking on Github?

[Walter Bender]

+1 for migrating. But... I think we need to send out a clear description of
what is expected of App developers ("transfer" their repos to sugarlabs)
and how to manage issues once the switch-over has occurred.

-walter

On Mon, May 16, 2016 at 11:13 PM, Dave Crossland  wrote:

> Hi
>
> Does anyone want to discuss any more objections with me, or can I migrate
> the issue tracking to Github now? :)
>
> Cheers
> Dave
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>


-- 
Walter Bender
Sugar Labs
http://www.sugarlabs.org

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Issue tracking on Github?

[Dave Crossland]

Hi

Does anyone want to discuss any more objections with me, or can I migrate
the issue tracking to Github now? :)

Cheers
Dave
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Issue tracking on Github?

[Dave Crossland]

Hi

On 25 April 2016 at 07:42, Devin  wrote:

> *If* GitLab and/or trac, for example, had the features of GitHub and had
> a plugin that weeded out spam would it *then* be preferable to GitHub?
>

Not for me: The primary reason Github is preferable for me is that it is
the system used by almost all other libre software projects. This means
Sugar will have the lowest barrier to entry for those already familiar with
it, and it means those not yet familiar with libre software development
will learn how to contribute to most projects.

I think this is what Jamie meant by "It would be easier for new developers
to find and contribute if it were on github"

-- 
Cheers
Dave
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Issue tracking on Github?

[Devin]

On 04/23/2016 11:26 PM, Dave Crossland wrote:
> On 20 April 2016 at 09:04, Dave Crossland  wrote:
>
>> > How to decide?
> ? :)
>

/*If*/ GitLab and/or trac, for example, had the features of GitHub and
had a plugin that weeded out spam would it */then/* be preferable to GitHub?

If so, I can send out an email to see if volunteers are available to
take to such a task. I need to do something similar for another
project--helping Harvard's MOOC use free/libre software instead of
proprietary Adobe Connect.

Thanks,
Devin
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Issue tracking on Github?

[Dave Crossland]

On 20 April 2016 at 09:04, Dave Crossland  wrote:

> How to decide?


? :)
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Issue tracking on Github?

[Dave Crossland]

Hi

On 20 April 2016 at 19:58, James Cameron  wrote:

> Solution 1 is a change that may lose ticket reporters,
>

Hmm, do you mean people will refuse to report tickets because its Github?


> and creates an
> environment where instead of there being one place to report tickets,
> the place to report will depend on diagnosis (isolation to component)
>
thus requiring diagnosis to occur before reporting.
>

Incorrect :) I think its fine to use the sugar repo's issue tracker as a
central place to report tickets, unless you already know where they go, and
then upon diagnosis the issue can potentially be re-filed under another
repo.


> Hopefully by bringing diagnosis into a mailing list somewhere.
>

I would ideally see sugar-dev made read-only and shift all developer
discussions to the issue tracker ;)


> Quality of the
> problem description will increase.  There will be many closed issues
> "not caused by this component." which will look good when it comes
> time to say how many issues were closed.
>

Incorrect; the issues should be kept open until they are resolved, although
they might link to issues filed in other repos.


> Solution 2 is further disruptive.
>

I actually like the idea of a "Sugar Lab On A Stick" which is to say, if
everything was in [a] distribute version control system repo[s], then the
repo[s] could be distributed to mostly-offline communities (using
outernet.is or similar) who could be productive for say 6 weeks or 6
months, and then their commits could find their way back to the central
Sugar Labs mothership repos - eg, via sneaker-net from village to town and
then uploaded. For that I think Github won't work, because the PR and issue
discussions are not kept in the repo. The best self-contained DVCS solution
I've seen to this is, as I said, www.fossil-scm.org, although there are
some git-based systems.

If Sugar Labs had just grown and grown, then I would be supporting (2). But
I think that the relative weakness of the overall project means that, as
Jamie said, we ought to redouble our focus on our 'core competencies'; I
think we ought to focus on growing the community, by re-orientating the
project to all the complementary projects going on around the world, and
consolidating on Github (where the vast majority of libre software projects
are run) will help that growth.

-- 
Cheers
Dave
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Issue tracking on Github?

[James Cameron]

My rethink.

Solution 1 might work, my estimate is 10% probability of it working.

Solution 2 might work, my estimate is 5% probability of it working.

Solution 0 is do nothing, the status quo, my estimate is 25%
probability of it working.

Solution 1 is a change that may lose ticket reporters, and creates an
environment where instead of there being one place to report tickets,
the place to report will depend on diagnosis (isolation to component),
thus requiring diagnosis to occur before reporting.  Hopefully by
bringing diagnosis into a mailing list somewhere.  Quality of the
problem description will increase.  There will be many closed issues
"not caused by this component." which will look good when it comes
time to say how many issues were closed.

Solution 2 is further disruptive.

On Wed, Apr 20, 2016 at 06:51:50PM +0530, Vishal Batchu wrote:
> Hi Dave,
> 
> When I started contributing to SugarLabs initially, I faced a similar problem.
> Searching for activities on Github, gitorious and then searching for bugs on
> trac etc. It would be great if it could all be moved to a single place where 
> it
> can be accessed easily.
> 
> Since there is a conflict among the members between the 2 solutions proposed,
> is it possible to let the developer community know why you, Walter and James
> are in favour of solution 1 whereas Devin and Sam are in favour of solution 2?
> That way we would also know about the problems that each of them would give
> rise to (if there are any), and could help us decide better.
> 
> Personally, I prefer solution 1.
> 
> Thanks,
> Vishal
> 
> On Wed, Apr 20, 2016 at 6:34 PM, Dave Crossland <[1]d...@lab6.com> wrote:
> 
> Hi
> 
> On 20 April 2016 at 08:35, Walter Bender <[2]walter.ben...@gmail.com>
> wrote:
> 
> While SLOB can vote on this, personally I think it is up to the
> developer community to decide.
> 
> Sure, that's reasonable. How does the developer community resolve
> conflicts? 
>  
> 
> Can you summarize the recent discussion to date and ask for a thumbs 
> up
> /down from active developers?
> 
>
> Problem:
> 
> Sugar's software development is scattered across trac, gitorious (which is
> now unmaintained), and github. I think this is harmful to Sugar primarily
> because it pushes away new contributors - love's email is a great example 
> -
> and secondarily because it makes existing contributor's lives more painful
> as - as Sam said - everything should be in 1 place; and also because - as
> Walter said - the systems team is spending needless time on these systems.
> 2 proposals emerged from the discussion:
>  
> Solution 1:
> 
> Consolidate on Github. Set trac and gitorious read only, and then making 
> it
> a static html archive, while moving all issue tracking and git hosting of
> each sugar repo to Github. 
> 
> Solution 2:
> 
> Abandon Github. Consolidate on our own systems; I guess this means setting
> up gogs or gitlab to replace gitorious, and perhaps something else to
> replace trac, and then removing each sugar repo from Github that we
> control, and regularly encouraging all sugar activities on github to move
> to our infrastructure.
> 
> Conflict:
> 
> It seems that myself, Walter and James are in favour of (1), and Devin and
> Sam are in favour of (2)
> 
> How to decide?
> 
> Cheers
> Dave
>
> ___
> Sugar-devel mailing list
> [3]Sugar-devel@lists.sugarlabs.org
> [4]http://lists.sugarlabs.org/listinfo/sugar-devel
> 
> References:
> 
> [1] mailto:d...@lab6.com
> [2] mailto:walter.ben...@gmail.com
> [3] mailto:Sugar-devel@lists.sugarlabs.org
> [4] http://lists.sugarlabs.org/listinfo/sugar-devel

> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel


-- 
James Cameron
http://quozl.netrek.org/
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Issue tracking on Github?

[Dave Crossland]

On 20 April 2016 at 09:54, Justin Overton  wrote:

> - It would be easier for new developers to find and contribute if it were
> on github


I agree, this is my primary reason for proposing (1) also: I think the
primary problem facing Sugar Labs is the small developer community, and so
I think consolidating the move to Github rather than on SL hosted services
is important for making progress on growing the active developer community.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Issue tracking on Github?

[Justin Overton]

Why I like GitHub best

   - It would be easier for new developers to find and contribute if it
   were on github
   - Support for "how to use git" would be mostly on github rather than
   SugarLab's systems
   - Getting existing developers to move their activities out of GitHub
   doesn't seem realistic. I know what I write will be in GitHub or BitBucket
   because I know those systems are stable and have longevity
   - SugarLabs should focus on core-competencies. Managing version control
   servers shouldn't be one of them.


On Wed, Apr 20, 2016 at 8:29 AM, Dave Crossland  wrote:

>
> On 20 April 2016 at 09:21, Vishal Batchu  wrote:
>
>> is it possible to let the developer community know why you, Walter and
>> James are in favour of solution 1 whereas Devin and Sam are in favour of
>> solution 2?
>
>
> Please read the thread :)
>
> http://lists.sugarlabs.org/archive/sugar-devel/2016-April/051788.html
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Issue tracking on Github?

[Dave Crossland]

On 20 April 2016 at 09:21, Vishal Batchu  wrote:

> is it possible to let the developer community know why you, Walter and
> James are in favour of solution 1 whereas Devin and Sam are in favour of
> solution 2?


Please read the thread :)

http://lists.sugarlabs.org/archive/sugar-devel/2016-April/051788.html
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Issue tracking on Github?

[Vishal Batchu]

Hi Dave,

When I started contributing to SugarLabs initially, I faced a similar
problem. Searching for activities on Github, gitorious and then searching
for bugs on trac etc. It would be great if it could all be moved to a
single place where it can be accessed easily.

Since there is a conflict among the members between the 2 solutions
proposed, is it possible to let the developer community know why you,
Walter and James are in favour of solution 1 whereas Devin and Sam are in
favour of solution 2? That way we would also know about the problems that
each of them would give rise to (if there are any), and could help us
decide better.

Personally, I prefer solution 1.

Thanks,
Vishal

On Wed, Apr 20, 2016 at 6:34 PM, Dave Crossland  wrote:

> Hi
>
> On 20 April 2016 at 08:35, Walter Bender  wrote:
>
>> While SLOB can vote on this, personally I think it is up to the developer
>> community to decide.
>
>
> Sure, that's reasonable. How does the developer community resolve
> conflicts?
>
>
>> Can you summarize the recent discussion to date and ask for a thumbs
>> up/down from active developers?
>
>
> *Problem:*
>
> Sugar's software development is scattered across trac, gitorious (which is
> now unmaintained), and github. I think this is harmful to Sugar primarily
> because it pushes away new contributors - love's email is a great example -
> and secondarily because it makes existing contributor's lives more painful
> as - as Sam said - everything should be in 1 place; and also because - as
> Walter said - the systems team is spending needless time on these systems.
> 2 proposals emerged from the discussion:
>
> *Solution 1:*
>
> Consolidate on Github. Set trac and gitorious read only, and then making
> it a static html archive, while moving all issue tracking and git hosting
> of each sugar repo to Github.
>
> *Solution 2:*
>
> Abandon Github. Consolidate on our own systems; I guess this means setting
> up gogs or gitlab to replace gitorious, and perhaps something else to
> replace trac, and then removing each sugar repo from Github that we
> control, and regularly encouraging all sugar activities on github to move
> to our infrastructure.
>
> *Conflict:*
>
> It seems that myself, Walter and James are in favour of (1), and Devin and
> Sam are in favour of (2)
>
> How to decide?
>
> Cheers
> Dave
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Issue tracking on Github?

[Dave Crossland]

Hi

On 20 April 2016 at 08:35, Walter Bender  wrote:

> While SLOB can vote on this, personally I think it is up to the developer
> community to decide.


Sure, that's reasonable. How does the developer community resolve
conflicts?


> Can you summarize the recent discussion to date and ask for a thumbs
> up/down from active developers?


*Problem:*

Sugar's software development is scattered across trac, gitorious (which is
now unmaintained), and github. I think this is harmful to Sugar primarily
because it pushes away new contributors - love's email is a great example -
and secondarily because it makes existing contributor's lives more painful
as - as Sam said - everything should be in 1 place; and also because - as
Walter said - the systems team is spending needless time on these systems.
2 proposals emerged from the discussion:

*Solution 1:*

Consolidate on Github. Set trac and gitorious read only, and then making it
a static html archive, while moving all issue tracking and git hosting of
each sugar repo to Github.

*Solution 2:*

Abandon Github. Consolidate on our own systems; I guess this means setting
up gogs or gitlab to replace gitorious, and perhaps something else to
replace trac, and then removing each sugar repo from Github that we
control, and regularly encouraging all sugar activities on github to move
to our infrastructure.

*Conflict:*

It seems that myself, Walter and James are in favour of (1), and Devin and
Sam are in favour of (2)

How to decide?

Cheers
Dave
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Issue tracking on Github?

[Walter Bender]

On Wed, Apr 20, 2016 at 8:30 AM, Dave Crossland  wrote:

>
> On 4 April 2016 at 10:19, Walter Bender  wrote:
>
>> 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.
>>
>
> With Love's email about being confused about where we track out bugs - and
> sadly blaming himself! - I would like to revive this topic.
>
> I guess since it is contentious, it requires a SLOBs vote.
>
> I'll draft a motion.
>
> -- Forwarded message --
> From: Dave Crossland 
> Date: 20 April 2016 at 08:28
> Subject: Re: [Sugar-devel] Any js related beginner bugs that I can work on
> To: sugar-devel 
>
>
>
> On 20 April 2016 at 04:59, Love Mehta  wrote:
>
>> I was feeling really dumb after not being able to find any bugs I could
>> work on.
>>
>
> I'm glad you would speak on this list to say that - another good reason
> for shutting down trac and moving the issue tracking to github since the
> source code is there :)
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
While SLOB can vote on this, personally I think it is up to the developer
community to decide. Can you summarize the recent discussion to date and
ask for a thumbs up/down from active developers?

regards.

-walter

-- 
Walter Bender
Sugar Labs
http://www.sugarlabs.org

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Issue tracking on Github?

[Walter Bender]

On Mon, Apr 4, 2016 at 10:08 AM, Dave Crossland  wrote:

>
> Hi!
>
> On 4 April 2016 at 00:50, Devin Ulibarri  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 > >,
>> > 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 , 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 

Re: [Sugar-devel] Issue tracking on Github?

[Dave Crossland]

Hi!

On 4 April 2016 at 00:50, Devin Ulibarri  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 ,
> > 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.

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 , 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 davecrosslandro...@gmail.com, so inevitably

Re: [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  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/
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Issue tracking on Github?

[Devin Ulibarri]

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 ,
> 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?

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

> 
> 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. "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)

>  
> 
> 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...

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.

Off to bed now.

Thanks!
Devin
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Issue tracking on Github?

[Dave Crossland]

Hi Tony!

On 3 April 2016 at 02:02, Tony Anderson  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
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Issue tracking on Github?

[Dave Crossland]

Hi Sam!

On 3 April 2016 at 01:12,  wrote:

> Hi Dave,
>
> On Sun, Apr 3, 2016 at 11:36 AM, Dave Crossland  wrote:
>
>
> Hi
>
> When sugar git moved from http://git.sugarlabs.org/sugar-old to
> https://github.com/sugarlabs/sugar  in 2013, why did issue tracking stay
> at bugs.sugarlabs.org and not move to
> https://github.com/sugarlabs/sugar/issues ?
>
>
> Why do we want to mix our coding and our program?  Our bug tracker is
> sorted by program (eg. Sugar, Write, TurtleBlocks), but our code as many
> more lines.  We need to make reporting bugs as easy as writing steps to
> reproduce.  Go and ask a student in a classroom and half can probably do
> that.  But none of them can tell you the difference between sugar shell and
> sugar toolkit gtk3 and sugar datastore (I don't even know what that does).
>

I think using Github issue tracking for each activity (and recommending
https://github.com/sugarlabs/sugar/issues/ as a default if there is any
ambiguity on where to file concerning sugar-desktop things) makes reporting
bugs easier for everyone, including kids :)

>
> I think it would be a good idea to move the issues, since pull requests
> can then be linked to issues (and even close them automatically by
> including "closes #issue_id" in the commit/pr message :) and development is
> concentrated in 1 place, with 1 UX.
>
>
> I'm pretty hyped that we use hyperlinks currently to link patches to
> issues.  That works fine.
>
> We still write "closed #X" in our commits.  We used to have something to
> automatically close it.  For some reason we decided to go back to manually
> closing tickets - separating the testing from the coding.
>

This is not really the most important reason for using Github - please see
my other earlier emails about that :)


>
> There are only 182 open issues on bugs.sugarlabs.org (
> https://bugs.sugarlabs.org/query?status=new=assigned=accepted=reopened=Sugar=priority)
> so moving them over would likely take one person 3-4 hours. I'm happy to do
> this if it would be helpful.
>
>
> No, open issues are not the only thing.  We need closed issues as well -
> all the commits, code comments, etc have references to them.  If we
> fragment the issue placement we will eventually forget about trac and loose
> the old issues.
>

I propose setting trac read only, and then making it a static html archive.

One place is better than 2.


Right - and since the code is developed on Github, we are already in 2
places, and I propose we consolidate on 1 place.


> If we migrate to a new platform, we also need to take care to keep the
> numbers the same.  That makes a github migration hard - it is a closed
> platform and we don't control that aspect of it.
>

I kindly disagree, I don't see much value in keeping numbers the same; I
agree that history is important, but I think all important needs are met
when the full URLs on bugs.sugarlabs.org remain accessible in a read-only
fashion.


> We need to choose a new platform that gives us more flexibility - maybe
> something like GitLab, Phabricator [1], Bugzilla or Trac.
>

I have explained in my other emails why I think all self-hosting options
are unwise :)

-- 
Cheers
Dave
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Issue tracking on Github?

[James Cameron]

On Sun, Apr 03, 2016 at 09:40:33PM -0400, Dave Crossland wrote:
> [...] Either strategy of landing on Github (as I recommend) or
> returning wholly to SL infrastructure (as Devlin has just proposed)
> would meet that goal. 

My preference is to move the remaining activities to GitHub and set
the Gitorious instance read-only.

-- 
James Cameron
http://quozl.netrek.org/
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Issue tracking on Github?

[Dave Crossland]

Hi Walter!

On 3 April 2016 at 20:27, Walter Bender  wrote:

> This means we have no users engaging with Sugar Labs through bug
>>> reporting; and that's been my observation for some time.
>>>
>>
>> I feel anxious to read this, and for me this is the primary reason I
>> propose consolidating the move to Github - to grow engagement.
>>
>> As a new contributor to this community, I find Sugar Labs' technical
>> development to be much more fragmented than other medium sized libre
>> software projects that I've contributed to (eg, Inkscape.) So I would like
>> to see it consolidated.
>>
>
> In part this is due to the nature of the project and the nature of our
> user/developer community. The desktop moved en-mass but Sugar activities
> have moved in fits and starts. Sugar has never hosted all of the Sugar
> activities, as many are developed in deployments and may or not be shared
> upstream.
>

Sure :)

The libre font community is similar; most projects use Github.com but some
use Gitlab.com or BitBucket.com or other 3rd party hosts, and some use
their own infrastructure. But there is not really any centralised
index/catalog/library of libre fonts.

For Activities, though, ASLO does seem to be the primary (if not the
central) index.

And the earlier discussion I read in the archives about including a repo
key in an activity's manifest sounds like really great step in this
direction, since it enables the migration to be measure and tracked to
completion.


> Also, arguably it was a mistake, but when we set up Sugar Labs, we tried
> to err on the side of decentralization and autonomy for developers and
> deployments. A benevolent dictator model might have resulted in less
> fragmentation, but perhaps less creativity. Water over the dam. But we
> should work towards making it easier to find source code, issues, etc.
> Thanks for pushing us on this... it often takes a new community member to
> get things moving.
>

I'm not sure what you mean by saying that the early set up of Sugar Labs
resulted in more creativity... Could you explain with an example or two of
something you think was creative and happened because of that set up?

I ask about this detail because I believe that how the early Sugar Labs was
set up (self-hosting central development infrastructure with Gitorious and
Trac instances) could now be done using an integrated code-and-issue host
(GitLab, Fossil, etc) and thus would not create any more or less
fragmentation than my proposed Sugar Labs Github set up will do.

The fragmentation that I can see is that migration to Github was made for
the desktop code but not activities or issues; and thus my goal is
consolidation.

Either strategy of landing on Github (as I recommend) or returning wholly
to SL infrastructure (as Devlin has just proposed) would meet that goal.

-- 
Cheers
Dave
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Issue tracking on Github?

[Dave Crossland]

On 3 April 2016 at 20:36, James Cameron  wrote:

>
> Previous attempts at consolidation have had varying success, as can be
> seen from the increase in fragmentation.
>
> The number of mailing lists, Wiki, Social Help, IRC channels,
> Gitorius, GitHub, ... these are all being used lightly, and the
> fragmentation of the community is harmful to survival.



...


> I'm expecting another effort to consolidate will cause further
> fragmentation.


:D

The reason I recommend for Github and against phabricator or another
self-hosted issue tracker/git host (or even against moving to Fossil SCM
which I think is the best solution I've seen for hosting project
infrastructure autonomously :) is that the sugar desktop code has already
moved there, and what I personally see as the future of sugar - sugarizer -
began there.

>
> > The move to Github seems to have already started in an uncoordinated
> > way,
> No, it was well coordinated and led, but it was not followed by many
> developers, who had already disengaged.  Some of their activities
> remain popular, and sometimes new developers take them on.


I apologies for casting previous efforts in a negative light, if I did so -
I don't mean to disparage anyone :)

> I don't think GitHub issues will work very well; because it
> > isn't easy to move an issue from one repository to another.
> > With trac, a ticket may be reported against one component, then
> > diagnosed to be fixed in another component.
> >
> > Would this work for you: open a new issue in the second component
> > with a first comment saying this picks up from the previous issue,
> > then in that first issue add a final comment pointing to the new
> > location in the first issue and close it :)
>
> A messy workflow.  But first, get users who want to raise issues, then
> see how it goes.


I am glad to accept :D


> Sorry, yes, my haste; privacy is a purchased service.


This is veering somewhat off topic, but I am generally concerned with how
to pay labor and maintain capital goods that advance the software freedom
movement.

In the case of project hosting, for me selling privacy seems like a more
reasonable way to fund development compared the (more typical) sale of
proprietary features, as https://about.gitlab.com/features/ does.


>
> You earlier wrote:
> > I believe that all github users that join a github organization will get
> > emailed every issue, pr, and comment for every github project within that
> > github organization.
>
> By the way, to be notified from trac, subscribe to
> http://lists.sugarlabs.org/listinfo/bugs


Done :)

-- 
Cheers
Dave
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Issue tracking on Github?

[Devin Ulibarri]

Hi,

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

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

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)

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.

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.

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, 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).

My two cents,

Devin
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Issue tracking on Github?

[James Cameron]

On Sun, Apr 03, 2016 at 08:15:26PM -0400, Dave Crossland wrote:
> 
> Hi James!
> 
> On 3 April 2016 at 18:35, James Cameron <[1]qu...@laptop.org> wrote:
> 
> Because trac provides coverage across multiple repositories, and
> nothing else gave us that feature at the time.
> 
> This makes good sense, and is good to know :)
>  
> 
> I'm fine with closing down trac, because;
> 
> (a) it isn't used in release engineering,
> 
> Is wiki.sugarlabs.org used for tracking release engineering work?

I'm not the release engineer for Sugar, sorry.  Good question though;
probably answer is yes, to some extent.

> (b) in the past 90 days there have been no tickets created or
> updated by anyone other than developers.  (see timeline of
> trac),
> 
> Thanks for pointing this out :)
>  
> 
> This means we have no users engaging with Sugar Labs through bug
> reporting; and that's been my observation for some time.
> 
> I feel anxious to read this, and for me this is the primary reason I
> propose consolidating the move to Github - to grow engagement.

Engagement growth is important; but it does not appear to be grown
with issue reporting on GitHub.  It is a distraction.

> As a new contributor to this community, I find Sugar Labs' technical
> development to be much more fragmented than other medium sized libre
> software projects that I've contributed to (eg, Inkscape.)

Yes.  The fragmentation is real.  The cause might be speculated about.

> So I would like to see it consolidated.

Best of luck.  ;-)

Previous attempts at consolidation have had varying success, as can be
seen from the increase in fragmentation.

The number of mailing lists, Wiki, Social Help, IRC channels,
Gitorius, GitHub, ... these are all being used lightly, and the
fragmentation of the community is harmful to survival.

> The move to Github seems to have already started in an uncoordinated
> way,

No, it was well coordinated and led, but it was not followed by many
developers, who had already disengaged.  Some of their activities
remain popular, and sometimes new developers take them on.

> and since so many libre software projects have or are moving to
> it, and one of the (perhaps unstated) goals of Sugar Labs is to
> introduce children to participating in libre software development, I
> think that it helps to use the same collaboration platform as most
> other project use.

I'm expecting another effort to consolidate will cause further
fragmentation.

> I don't think GitHub issues will work very well; because it
> isn't easy to move an issue from one repository to another. 
> With trac, a ticket may be reported against one component, then
> diagnosed to be fixed in another component.
> 
> Would this work for you: open a new issue in the second component
> with a first comment saying this picks up from the previous issue,
> then in that first issue add a final comment pointing to the new
> location in the first issue and close it :)

A messy workflow.  But first, get users who want to raise issues, then
see how it goes.

> Github makes this easy because it will add backlinks in the
> destination issue's timeline when that issue is mentioned in the
> original; and it will automatically create such links if you type
> user/repo#issueNumber :) 
> 
> As an example of this back-linking, see these 2 links,
> 
> https://github.com/llaske/sugarizer/issues/49 (link at end of first post)
> 
> https://github.com/mattlag/Glyphr-Studio/issues/234 (currently link is at
> the bottom :) 
>  
> 
> Some GitHub project teams can use a single issue tracker for a set of
> repositories.  endlessm is one such user, with commits referencing a
> "shell" of issues.
> 
> Oh yes! I remember the announcement of that company's first product,
> but I did not pay any further attention since then (and now) it
> isn't possible to download an iso to play with in a VM. 
> 
> I found sucha  commit - https://github.com/endlessm/
> eos-event-recorder-daemon/commit/4c4704f516adcdf0d287a29b972a49c5978d603f - 
> and
> they are using a private issue tracker, https://phabricator.endlessm.com . I
> feel disappointed :)

Yes, they have moved to phabricator, but they were using a shell/issue
private project on GitHub.

> These may be features of GitHub that have a purchase price, but I don't
> know.
> 
> I am pretty sure that Github doesn't price features like that; all
> the features are available to non-paying users. 
> 
> Instead of charging for features, they are charging for privacy; the
> requirement for non-paying users is that all those users repos are
> public; the only thing that they charge for is how many users can
> participate in private repos. https://github.com/pricing/plans
> explains this, and as a Github user for nearly 6 years that is my
> experience, no gotchas. 

Sorry, yes, my haste; privacy is a purchased service.

You earlier wrote:
> I believe that all github users that join a github organization 

Re: [Sugar-devel] Issue tracking on Github?

[Dave Crossland]

Hi Walter!

On 3 April 2016 at 09:04, Walter Bender  wrote:

>
>
> On Sun, Apr 3, 2016 at 12:24 AM, Dave Crossland  wrote:
>
>>
>> On 2 April 2016 at 22:21, Walter Bender  wrote:
>>
>>> I was just asking (again) the other day
>>>
>>
>> Can you provide a URL for where you asked about this? :)
>>
>
> I was asking in a private email with scg who maintains out trac instance.
>

Ah okay, cool :)



> if someone has an issue aggregation tool since our issues are scattered
>>> across multiple repositories. Presumably we are not the first to have
>>> bumped into this problem.
>>
>>
>> I don't understand what you mean :)
>>
>> Assuming that Github is now the central hosting service for Sugar Labs, I
>> expect each logical sugar labs project that is 'official' to have its
>> central git repository hosted in the sugarlabs github organization, and to
>> have its own issue tracker.
>>
>> Since Github automatically places backlinks in issues that are referred
>> to by other issuer or PRs, it is relatively convenient to manage the set of
>> a github organization's per-repo issue trackers.
>>
>> Some free software projects even set up github projects solely to use the
>> issue tracker as a discussion forum, eg https://github.com/ipfs/faq/
>>
>> I believe that all github users that join a github organization will get
>> emailed every issue, pr, and comment for every github project within that
>> github organization.
>>
>> I would also assume that all non-github issue trackers would be
>> configured to prominently direct users to the new github url, and disallow
>> new issues, or simply to have their theme templates hide the 'new issue'
>> link, and eventually to be configured read only and then fully archived by
>> conversion to a static HTML site.
>>
>

Here is the problem as I see it (and as Tony mentioned earlier). A large
> percentage of Sugar code (activity source) is not hosted on
> github.com/sugarlabs, although more and more of it is hosted on github.
>

That seems fine to me, since actively maintained code can be migrated to
Github.

Are there any other places in addition to git.sugarlabs.org and
github.com/sugarlabs?


> So many issues are not found in repos within the Sugar Labs "github"
> organization. How do developers hear about these issues? How do potential
> contributors search for these issues? How do users know where to post an
> issue?
>

I think all 3 questions are answered by co-ordinating a consolidating
migration to Github :)

1. Notification. This is handled due to the way that Github org membership
works; Github-users in a 'developers' Github-team within the
Github-organization will be emailed all posts to all repos that are added
to that team (done here, http://imgur.com/gUTNFfV)

2. Search. Github provides org-wide search, and this is discoverable when
you visit github.com/sugarlabs the search input widget at the top changes
to show that the search is scoped to that organization. After entering a
search query, a familiar search syntax is used in the query, and in the URL
string. Eg, https://github.com/search?q=org%3Afontforge+x11=Issues

3. Discoverability. I think that each repo should have its own issue
tracker, and so the url github.com/sugarlabs/activity-name/issues is
predictable. When a repo is moved to the github.com/sugarlabs org, a
checklist could be run over to ensure each activity's /README.md file (that
Github presents on github.com/sugarlabs/activity-name as processed
markdown) has explicit information about the issue tracker.


> If there was a mechanism for aggregating issues across multiple disperse
> repos, we could address most of my issues with migrating from trac.
>

For release management, I think Github doesn't discriminate between
aggregating a list of issues in 1 repo or 1 org or globally in Github.

I used Github in this way in FontForge release management when I was
contributing that labour, eg
https://github.com/fontforge/fontforge/issues/2083


> This is not rocket science, but it is something someone has to build
> and/or maintain. (I just noted in a later thread that you suggest we clone
> all activity repos into the Sugar Labs organization which would address at
> least part of my concern. Still not sure how people search for issues
> across multiple repos.)
>

:)


> (One other trivial question about issues: is there a way to build a
> standardized system of issue tags across multiple repos in an automated
> way? I presume with the github API we could do it.)
>

I'm not sure, but at worst this would be part of the checklist to run
through when accepting a repo transfer into the sugarlabs org.

-- 
Cheers
Dave
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Issue tracking on Github?

[Walter Bender]

On Sun, Apr 3, 2016 at 8:15 PM, Dave Crossland  wrote:

>
> Hi James!
>
> On 3 April 2016 at 18:35, James Cameron  wrote:
>
>> Because trac provides coverage across multiple repositories, and
>> nothing else gave us that feature at the time.
>>
>
> This makes good sense, and is good to know :)
>
>
>> I'm fine with closing down trac, because;
>>
>> (a) it isn't used in release engineering,
>>
>
> Is wiki.sugarlabs.org used for tracking release engineering work?
>
>
>> (b) in the past 90 days there have been no tickets created or updated
>> by anyone other than developers.  (see timeline of trac),
>>
>
> Thanks for pointing this out :)
>
>
>> This means we have no users engaging with Sugar Labs through bug
>> reporting; and that's been my observation for some time.
>>
>
> I feel anxious to read this, and for me this is the primary reason I
> propose consolidating the move to Github - to grow engagement.
>
> As a new contributor to this community, I find Sugar Labs' technical
> development to be much more fragmented than other medium sized libre
> software projects that I've contributed to (eg, Inkscape.) So I would like
> to see it consolidated.
>

In part this is due to the nature of the project and the nature of our
user/developer community. The desktop moved en-mass but Sugar activities
have moved in fits and starts. Sugar has never hosted all of the Sugar
activities, as many are developed in deployments and may or not be shared
upstream. Also, arguably it was a mistake, but when we set up Sugar Labs,
we tried to err on the side of decentralization and autonomy for developers
and deployments. A benevolent dictator model might have resulted in less
fragmentation, but perhaps less creativity. Water over the dam. But we
should work towards making it easier to find source code, issues, etc.
Thanks for pushing us on this... it often takes a new community member to
get things moving.

-walter

>
> The move to Github seems to have already started in an uncoordinated way,
> and since so many libre software projects have or are moving to it, and one
> of the (perhaps unstated) goals of Sugar Labs is to introduce children to
> participating in libre software development, I think that it helps to use
> the same collaboration platform as most other project use.
>
>
>> I don't think GitHub issues will work very well; because it isn't easy
>> to move an issue from one repository to another.  With trac, a ticket
>> may be reported against one component, then diagnosed to be fixed in
>> another component.
>>
>
> Would this work for you: open a new issue in the second component with a
> first comment saying this picks up from the previous issue, then in that
> first issue add a final comment pointing to the new location in the first
> issue and close it :)
>
> Github makes this easy because it will add backlinks in the destination
> issue's timeline when that issue is mentioned in the original; and it will
> automatically create such links if you type user/repo#issueNumber :)
>
> As an example of this back-linking, see these 2 links,
>
> https://github.com/llaske/sugarizer/issues/49 (link at end of first post)
>
> https://github.com/mattlag/Glyphr-Studio/issues/234 (currently link is at
> the bottom :)
>
>
>> Some GitHub project teams can use a single issue tracker for a set of
>> repositories.  endlessm is one such user, with commits referencing a
>> "shell" of issues.
>>
>
> Oh yes! I remember the announcement of that company's first product, but I
> did not pay any further attention since then (and now) it isn't possible to
> download an iso to play with in a VM.
>
> I found sucha  commit -
> https://github.com/endlessm/eos-event-recorder-daemon/commit/4c4704f516adcdf0d287a29b972a49c5978d603f
> - and they are using a private issue tracker,
> https://phabricator.endlessm.com . I feel disappointed :)
>
>
>> These may be features of GitHub that have a purchase price, but I don't
>> know.
>>
>
> I am pretty sure that Github doesn't price features like that; all the
> features are available to non-paying users.
>
> Instead of charging for features, they are charging for privacy; the
> requirement for non-paying users is that all those users repos are public;
> the only thing that they charge for is how many users can participate in
> private repos. https://github.com/pricing/plans explains this, and as a
> Github user for nearly 6 years that is my experience, no gotchas.
>
> --
> Cheers
> Dave
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>


-- 
Walter Bender
Sugar Labs
http://www.sugarlabs.org

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Issue tracking on Github?

[Dave Crossland]

Hi James!

On 3 April 2016 at 18:35, James Cameron  wrote:

> Because trac provides coverage across multiple repositories, and
> nothing else gave us that feature at the time.
>

This makes good sense, and is good to know :)


> I'm fine with closing down trac, because;
>
> (a) it isn't used in release engineering,
>

Is wiki.sugarlabs.org used for tracking release engineering work?


> (b) in the past 90 days there have been no tickets created or updated
> by anyone other than developers.  (see timeline of trac),
>

Thanks for pointing this out :)


> This means we have no users engaging with Sugar Labs through bug
> reporting; and that's been my observation for some time.
>

I feel anxious to read this, and for me this is the primary reason I
propose consolidating the move to Github - to grow engagement.

As a new contributor to this community, I find Sugar Labs' technical
development to be much more fragmented than other medium sized libre
software projects that I've contributed to (eg, Inkscape.) So I would like
to see it consolidated.

The move to Github seems to have already started in an uncoordinated way,
and since so many libre software projects have or are moving to it, and one
of the (perhaps unstated) goals of Sugar Labs is to introduce children to
participating in libre software development, I think that it helps to use
the same collaboration platform as most other project use.


> I don't think GitHub issues will work very well; because it isn't easy
> to move an issue from one repository to another.  With trac, a ticket
> may be reported against one component, then diagnosed to be fixed in
> another component.
>

Would this work for you: open a new issue in the second component with a
first comment saying this picks up from the previous issue, then in that
first issue add a final comment pointing to the new location in the first
issue and close it :)

Github makes this easy because it will add backlinks in the destination
issue's timeline when that issue is mentioned in the original; and it will
automatically create such links if you type user/repo#issueNumber :)

As an example of this back-linking, see these 2 links,

https://github.com/llaske/sugarizer/issues/49 (link at end of first post)

https://github.com/mattlag/Glyphr-Studio/issues/234 (currently link is at
the bottom :)


> Some GitHub project teams can use a single issue tracker for a set of
> repositories.  endlessm is one such user, with commits referencing a
> "shell" of issues.
>

Oh yes! I remember the announcement of that company's first product, but I
did not pay any further attention since then (and now) it isn't possible to
download an iso to play with in a VM.

I found sucha  commit -
https://github.com/endlessm/eos-event-recorder-daemon/commit/4c4704f516adcdf0d287a29b972a49c5978d603f
- and they are using a private issue tracker,
https://phabricator.endlessm.com . I feel disappointed :)


> These may be features of GitHub that have a purchase price, but I don't
> know.
>

I am pretty sure that Github doesn't price features like that; all the
features are available to non-paying users.

Instead of charging for features, they are charging for privacy; the
requirement for non-paying users is that all those users repos are public;
the only thing that they charge for is how many users can participate in
private repos. https://github.com/pricing/plans explains this, and as a
Github user for nearly 6 years that is my experience, no gotchas.

-- 
Cheers
Dave
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Issue tracking on Github?

[James Cameron]

Because trac provides coverage across multiple repositories, and
nothing else gave us that feature at the time.

I'm fine with closing down trac, because;

(a) it isn't used in release engineering,

(b) in the past 90 days there have been no tickets created or updated
by anyone other than developers.  (see timeline of trac),

This means we have no users engaging with Sugar Labs through bug
reporting; and that's been my observation for some time.

I don't think GitHub issues will work very well; because it isn't easy
to move an issue from one repository to another.  With trac, a ticket
may be reported against one component, then diagnosed to be fixed in
another component.

Some GitHub project teams can use a single issue tracker for a set of
repositories.  endlessm is one such user, with commits referencing a
"shell" of issues.  These may be features of GitHub that have a
purchase price, but I don't know.

On Sat, Apr 02, 2016 at 09:36:35PM -0400, Dave Crossland wrote:
> 
> Hi
> 
> When sugar git moved from [1]http://git.sugarlabs.org/sugar-old to [2]https://
> github.com/sugarlabs/sugar  in 2013, why did issue tracking stay at [3]
> bugs.sugarlabs.org and not move to 
> [4]https://github.com/sugarlabs/sugar/issues
> ?
> 
> I think it would be a good idea to move the issues, since pull requests can
> then be linked to issues (and even close them automatically by including
> "closes #issue_id" in the commit/pr message :) and development is concentrated
> in 1 place, with 1 UX.
> 
> There are only 182 open issues on [5]bugs.sugarlabs.org ([6]https://
> bugs.sugarlabs.org/query?status=new=assigned=accepted=
> reopened=Sugar=priority) so moving them over would likely take
> one person 3-4 hours. I'm happy to do this if it would be helpful. 
> 
> --
> Cheers
> Dave
> 
> References:
> 
> [1] http://git.sugarlabs.org/sugar-old
> [2] https://github.com/sugarlabs/sugar
> [3] http://bugs.sugarlabs.org/
> [4] https://github.com/sugarlabs/sugar/issues
> [5] http://bugs.sugarlabs.org/
> [6] 
> https://bugs.sugarlabs.org/query?status=new=assigned=accepted=reopened=Sugar=priority

> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel


-- 
James Cameron
http://quozl.netrek.org/
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Issue tracking on Github?

[Walter Bender]

On Sun, Apr 3, 2016 at 12:24 AM, Dave Crossland  wrote:

>
> On 2 April 2016 at 22:21, Walter Bender  wrote:
>
>> I was just asking (again) the other day
>>
>
> Can you provide a URL for where you asked about this? :)
>

I was asking in a private email with scg who maintains out trac instance.
He had asked me what if anything needing doing and I mentioned that it
would be great to migrate to issues if there was (and presumably there is)
a means of aggregating among a collection of repos. (I will check to
confirm it was in a private thread).

>
> if someone has an issue aggregation tool since our issues are scattered
>> across multiple repositories. Presumably we are not the first to have
>> bumped into this problem.
>
>
> I don't understand what you mean :)
>
> Assuming that Github is now the central hosting service for Sugar Labs, I
> expect each logical sugar labs project that is 'official' to have its
> central git repository hosted in the sugarlabs github organization, and to
> have its own issue tracker.
>
> Since Github automatically places backlinks in issues that are referred to
> by other issuer or PRs, it is relatively convenient to manage the set of a
> github organization's per-repo issue trackers.
>
> Some free software projects even set up github projects solely to use the
> issue tracker as a discussion forum, eg https://github.com/ipfs/faq/
>
> I believe that all github users that join a github organization will get
> emailed every issue, pr, and comment for every github project within that
> github organization.
>
> I would also assume that all non-github issue trackers would be configured
> to prominently direct users to the new github url, and disallow new issues,
> or simply to have their theme templates hide the 'new issue' link, and
> eventually to be configured read only and then fully archived by conversion
> to a static HTML site.
>
>
> Here is the problem as I see it (and as Tony mentioned earlier). A large
percentage of Sugar code (activity source) is not hosted on
github.com/sugarlabs, although more and more of it is hosted on github. So
many issues are not found in repos within the Sugar Labs "github"
organization. How do developers hear about these issues? How do potential
contributors search for these issues? How do users know where to post an
issue? If there was a mechanism for aggregating issues across multiple
disperse repos, we could address most of my issues with migrating from
trac. This is not rocket science, but it is something someone has to build
and/or maintain. (I just noted in a later thread that you suggest we clone
all activity repos into the Sugar Labs organization which would address at
least part of my concern. Still not sure how people search for issues
across multiple repos.)

(One other trivial question about issues: is there a way to build a
standardized system of issue tags across multiple repos in an automated
way? I presume with the github API we could do it.)

-walter


-- 
Walter Bender
Sugar Labs
http://www.sugarlabs.org

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Issue tracking on Github?

[Tony Anderson]

Welcome to the Sugar community (and its growing entropy)!

You are proposing, appropriately, a new way to handle version control 
for Sugar.


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.


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.


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. As far as I know, SOAS does not offer an 'install' 
option.


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.


Tony

On 04/03/2016 12:38 PM, Dave Crossland wrote:


On 2 April 2016 at 22:18, Tony Anderson > wrote:


The Sugar activities, which represent 90% or more of the Sugar
lines of code, are being relocated to the github accounts of
individual developer/maintainers - not under a single Sugar account.


I think that is fine :) If they would like to make their activity 
'official' then they can ask to be invited to the github.com/sugarlabs 
 organization, and then after they accept 
the invitation, they can go to github.com/username/repo/settings 
 and at the bottom move the 
repo to the org.


(Or, someone who has joined the org with appropriate permissions can 
fork their repo into the org, to maintain an 'official' copy of it, 
and the initial developer or anyone else can then make pull requests 
to it. However, I think the first way is better since then Github will 
show that as the 'upstream' repo on network graph pages, eg 
https://github.com/sugarlabs/sugar/network)


At the moment this information is recorded in the activity.info
 file of the activity itself. This change
has not yet been implemented across all of the activities.


Cool - that seems like a good milestone for Sugar Labs this year. I 
added it to https://wiki.sugarlabs.org/go/Vision_proposal_2016


I don't understand the process. However, it appears that OLPC
makes the release images. It decides which Sugar activities will
be included in a release. I gather that SugarLabs has no say in this.


That sounds great to me :)

As I understand it, Sugar is a desktop environment for all computers 
that can run GNU, while OLPC makes "OLPC OS," which is a GNU 
distribution tailored to XO laptops that packages Sugar and GNOME 
desktops.


I don't know the technical details, but it would seem desirable to
separate issue tracking into separate Sugar and Sugar activity
branches.


That is unavoidable with the way Github is designed.

The issues for Sugar related to releases (e.g. 0.108) and for
Sugar activities to version numbers. Update to Sugar activities
are independent from Sugar releases.


However, surely some Sugar releases are requirements for some activity 
versions? Eg, Chat 78 
(http://activities.sugarlabs.org/en-US/sugar/addon/4069) says it 
requires a Sugar release of 0.86 or higher (and may not work with 
0.108, according to the metadata on that page)


--
Cheers
Dave


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Issue tracking on Github?

[sam]

Hi Dave,

On Sun, Apr 3, 2016 at 11:36 AM, Dave Crossland  wrote:


Hi

When sugar git moved from http://git.sugarlabs.org/sugar-old to 
https://github.com/sugarlabs/sugar  in 2013, why did issue tracking 
stay at bugs.sugarlabs.org and not move to 
https://github.com/sugarlabs/sugar/issues ?


Why do we want to mix our coding and our program?  Our bug tracker is 
sorted by program (eg. Sugar, Write, TurtleBlocks), but our code as 
many more lines.  We need to make reporting bugs as easy as writing 
steps to reproduce.  Go and ask a student in a classroom and half can 
probably do that.  But none of them can tell you the difference between 
sugar shell and sugar toolkit gtk3 and sugar datastore (I don't even 
know what that does).




I think it would be a good idea to move the issues, since pull 
requests can then be linked to issues (and even close them 
automatically by including "closes #issue_id" in the commit/pr 
message :) and development is concentrated in 1 place, with 1 UX.


I'm pretty hyped that we use hyperlinks currently to link patches to 
issues.  That works fine.


We still write "closed #X" in our commits.  We used to have something 
to automatically close it.  For some reason we decided to go back to 
manually closing tickets - separating the testing from the coding.




There are only 182 open issues on bugs.sugarlabs.org 
(https://bugs.sugarlabs.org/query?status=new=assigned=accepted=reopened=Sugar=priority) 
so moving them over would likely take one person 3-4 hours. I'm happy 
to do this if it would be helpful.


No, open issues are not the only thing.  We need closed issues as well 
- all the commits, code comments, etc have references to them.  If we 
fragment the issue placement we will eventually forget about trac and 
loose the old issues.  One place is better than 2.


If we migrate to a new platform, we also need to take care to keep the 
numbers the same.  That makes a github migration hard - it is a closed 
platform and we don't control that aspect of it.  We need to choose a 
new platform that gives us more flexibility - maybe something like 
GitLab, Phabricator [1], Bugzilla or Trac.


Thanks,
Sam

[1] https://phabricator.wikimedia.org/


--
Cheers
Dave
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Issue tracking on Github?

[Dave Crossland]

On 2 April 2016 at 22:18, Tony Anderson  wrote:

> The Sugar activities, which represent 90% or more of the Sugar lines of
> code, are being relocated to the github accounts of individual
> developer/maintainers - not under a single Sugar account.
>

I think that is fine :) If they would like to make their activity
'official' then they can ask to be invited to the github.com/sugarlabs
organization, and then after they accept the invitation, they can go to
github.com/username/repo/settings and at the bottom move the repo to the
org.

(Or, someone who has joined the org with appropriate permissions can fork
their repo into the org, to maintain an 'official' copy of it, and the
initial developer or anyone else can then make pull requests to it.
However, I think the first way is better since then Github will show that
as the 'upstream' repo on network graph pages, eg
https://github.com/sugarlabs/sugar/network)


> At the moment this information is recorded in the activity.info file of
> the activity itself. This change has not yet been implemented across all of
> the activities.
>

Cool - that seems like a good milestone for Sugar Labs this year. I added
it to https://wiki.sugarlabs.org/go/Vision_proposal_2016


> I don't understand the process. However, it appears that OLPC makes the
> release images. It decides which Sugar activities will be included in a
> release. I gather that SugarLabs has no say in this.
>

That sounds great to me :)

As I understand it, Sugar is a desktop environment for all computers that
can run GNU, while OLPC makes "OLPC OS," which is a GNU distribution
tailored to XO laptops that packages Sugar and GNOME desktops.


> I don't know the technical details, but it would seem desirable to
> separate issue tracking into separate Sugar and Sugar activity branches.
>

That is unavoidable with the way Github is designed.


> The issues for Sugar related to releases (e.g. 0.108) and for Sugar
> activities to version numbers. Update to Sugar activities are independent
> from Sugar releases.
>

However, surely some Sugar releases are requirements for some activity
versions? Eg, Chat 78 (
http://activities.sugarlabs.org/en-US/sugar/addon/4069) says it requires a
Sugar release of 0.86 or higher (and may not work with 0.108, according to
the metadata on that page)

-- 
Cheers
Dave
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Issue tracking on Github?

[Tony Anderson]

I am sure this would be helpful. However, the situation seems a bit more 
muddled.


The Sugar activities, which represent 90% or more of the Sugar lines of 
code, are being relocated to the github accounts of individual 
developer/maintainers - not under a single Sugar account. At the moment 
this information is recorded in the activity.info file of the activity 
itself. This change has not yet been implemented across all of the 
activities.


I don't understand the process. However, it appears that OLPC makes the 
release images. It decides which Sugar activities will be included in a 
release.

I gather that SugarLabs has no say in this.

I don't know the technical details, but it would seem desirable to 
separate issue tracking into separate Sugar and Sugar activity branches. 
The issues for Sugar related to releases (e.g. 0.108) and for Sugar 
activities to version numbers. Update to Sugar activities are 
independent from Sugar releases.


Tony

On 04/03/2016 09:36 AM, Dave Crossland wrote:


Hi

When sugar git moved from http://git.sugarlabs.org/sugar-old to 
https://github.com/sugarlabs/sugar  in 2013, why did issue tracking 
stay at bugs.sugarlabs.org  and not move to 
https://github.com/sugarlabs/sugar/issues ?


I think it would be a good idea to move the issues, since pull 
requests can then be linked to issues (and even close them 
automatically by including "closes #issue_id" in the commit/pr message 
:) and development is concentrated in 1 place, with 1 UX.


There are only 182 open issues on bugs.sugarlabs.org 
 
(https://bugs.sugarlabs.org/query?status=new=assigned=accepted=reopened=Sugar=priority) 
so moving them over would likely take one person 3-4 hours. I'm happy 
to do this if it would be helpful.


--
Cheers
Dave


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel