[ASLO] [Sugar-devel] Activities added to GithHub

[Tony Anderson]

Hi, James

You have to move to experience friction.  It this effort were not 
important to the community, there wouldn't have been so much comment. 
Had some members not been concerned that some stranger, an unqualified 
senile newbie, was vandalizing the system, we would not have seen 
comments like 'information was destroyed'. Even beginners know that 
copying a file does not alter the original.

We might have seen a comment like 'The way you are creating repositories 
from ASLO ignores the repositories on git.sugarlabs.org. This mean the 
repositories you create do not have the history of git commits available 
there. Please copy the repositories from git.sugarlabs.org where they 
exist.'

Our two objectives are similar and mutually supporting.  Move all of the 
repositories on git.sugarlabs.org to github so that it no longer needs 
to be maintained. Make repositories on github for all of the activities 
on activities.sugarlabs.org so that the 'developer hub' can be shut down 
and that activities.sugarlabs.org site be simplified and made easier to 
maintain.

Working as a team and community, we can decide what we want to do and 
how it should be done. I have some time available and feel strongly that 
activities.sugarlabs.org as the storehouse of the crown jewels needs 
some serious attention.

ASLO (activities.sugarlabs.org) is our library of activities which users 
can download and run with Sugar. In order not to discourage them, it is 
important that these activities work on Sugar. This concern is led to 
testing the activities with Ubuntu (showing less that half work).

ASLO is not an app store. We don't have apps, we have activities. We do 
not and can not sell them.

Tony


On 04/24/2017 12:28 PM, James Cameron wrote:
> On Mon, Apr 24, 2017 at 11:48:16AM +0800, Tony Anderson wrote:
>> 1. The original repository is ASLO.
> No, the originals were mostly on laptop.org and on developer web
> sites, including Gitorious and GitHub.
>
>> The git.sugarlabs.org was added later.
> No, the Sugar Labs Gitorious instance was set up in 2009 before ASLO
> was brought up later that year.
>
> But ASLO is an app store, not version control.
>
>> The intent, as I understand it, is to have the master source code
>> under git version control on github as a replacement for
>> git.sugarlabs.org.
> No, the intent, as I understand it, is to move any still-remaining
> activities from git.sugarlabs.org to github.com so that
> git.sugarlabs.org can be shut down.
>
>> The git record of the programming change from version to version
>> should be invaluable in understanding how the activity evolved.
> No, not really.  What is valuable is the commit history, not the
> change from each release version.
>
> I think you might be thinking that "version control" has a direct
> relationship with release version numbers.  It doesn't.
>
> Perhaps "revision control" is the better term for what we use Git for.
>
>> Out of 71 repositories, 47 were not
>> duplicates and so development history has been captured.
> A history was captured, but it was not the commit history, so
> information was destroyed.
>
>> I assume you know that ASLO is short for
>> activities.sugarlabs.org. It is not source code.
> No, you're wrong.  ASLO is a web application with source code.  Go
> look at it http://github.com/sugarlabs/aslo
>
>> Yes, the original idea of ASLO is that individuals would create and
>> submit activities. The permission schemes does not permit community
>> maintenance.
> The ASLO permissions scheme is written in source code of ASLO and
> lists people as activity maintainers.
>
> I think your main problem is that on GitHub is much easier to add new
> users than it is on ASLO; because Aleksey and others who operate ASLO
> are less available than GitHub.
>
>> I believe the goal is to create a repository for each activity on
>> ASLO so that the community can undertake further development and
>> maintenance.
> I think you're trying to substitute a more accessible permission
> scheme by defaulting to GitHub.
>
>> 2. Certainly if the community decides this was a bad idea, it can be
>> easily corrected. However, this deserves discussion more than rants.
> Indeed, right back at you.
>
>> 3. There was a lot of discussion of this issue in connection with
>> GCI 2016 where making these ports was the main task. This is when
>> most of the 137 activities were added to the github/sugarlabs.
> Interesting, thanks.  That may explain something; any discussion that
> happened during GCI 2016 inside the Google Code-In framework won't
> have captured opinions of those not engaged in GCI.
>
>> I fully agree with the concern about dilution - I believe we should
>> have a separate organizational github (e.g sugar-activities) for the
>> activities.
> Huh?  You have misunderstood my earlier mail; concern about the dilution
> of the sugarlabs GitHub organisation by having a sugar-activities
> organisation.
>
>> However, the current course was adopted over a year ago and has not
>> been further discussed.
>>
>> The comment that everything  done was mechanical and unqualified is
>> spot on. My faux pas with the duplicates is clear evidence of my
>> being unqualified. I hope to prove educable.
>>
>> 4. Here are some issues that deserve thought and comment.
>>
>> In ASLO, the submitter specifies the license. The submitter is the
>> assumed copyright owner. So can we assign a different license on
>> github. Unfortuately the submitters choice of license is not
>> displayed on ASLO but I have to believe it was recorded in the mysql
>> database.
> Yes, the license is not displayed to the app store user, but that's
> peripheral to whether a license is declared in the source code in the
> bundle.  You can review the ASLO source code to see it was recorded.
>
>> I believe the activity.info should include the developer, summary,
>> description, and license as well as a link to the repository on
>> github plus any other valuable information displayed on ASLO. In
>> this way, the ASLO site can display information provided and
>> maintainable by the developer. This requires revisiting the current
>> definition of activity.info. Perhaps the Readme file could contain
>> this supplemental information to be added to the bundle by
>> bundlebuilder.
> That seems an unrelated issue, and I don't think this thread is the
> place to bring it up.
>