[Sugar-devel] Minor update to Make Your Own Sugar Activities!

Alex Perez aperez at alexperez.com
Mon Mar 13 23:02:57 EDT 2017


Tony/Walter,

> On Mar 13, 2017, at 7:28 PM, Walter Bender <walter.bender at gmail.com> wrote:
> 
> Tony,
> 
> Not sure I agree about your asserts regarding github vs gitroious.

Count me in here..
> 
> (1) the were/are many activities that were not hosted in gitorious long before we switched to github, so it wasn't obvious where to find the source repo *before* the switch. This is one of the reasons I started add the repo path to the activity.info <http://activity.info/> file.
> (2) ALSO needs work and maintenance regardless of where the repos are hosted.

And it is incumbent upon Sugar Labs and the board to ensure that this happens, even if it requires you to spend actual money to make it happen.
> 
> -walter
> 
> On Mon, Mar 13, 2017 at 10:02 PM, Tony Anderson <tony_anderson at usa.net <mailto:tony_anderson at usa.net>> wrote:
> Hi James,
> 
> Your book is a wonder and should be much more actively promoted. It is one of the major contributions of Sugar to constructive learning.
> 
> I believe the use of git.sugarlabs.org <http://git.sugarlabs.org/> and github are major steps backwards from the original conception of Sugar activities as something which users could develop and make available to the community.

Why do you believe this? It’s simply a convention for version control, one which millions of people understand, and does not preclude the use of the latter mechanism you describe. They are not mutually exclusive. Additionally, anyone can download a tarball/zip file of source code, or of a tagged release, from github, even if they have zero clue about how git works. Git is a convenience for *developers*

> In the first place, the activity bundle contains the source code that is actually being executed. Second, there is a simple version system in activity.info <http://activity.info/>. The Developer Hub at activities.sugarlabs.org <http://activities.sugarlabs.org/> supplies an adequate means to control maintenance activities (in the PR sense of having someone monitor changes before releasing them for general use). 

We do definitely need to expand upon the filtering abilities, to prevent, say, an x86-only activity from being installed on ARM, and vice versa.
> 
> If one wanted to update an activity, say TuxMath, now the first step would be to clone the repository not install the activity itself. 

This is an incorrect assumption. 
> 
> The ASLO site needs some work. Currently, the latest version is not necessarily exposed (see Browse or TuxMath, for example). In some cases, activities do not support Arm or use Hulahop and there is no way to specify which versions of Sugar or its platforms are supported. The availability of maintainers who know the PhP implementation of ASLO is apparently dwindling. Perhaps Sugar Labs could undertake to re-implement ASLO using Python (Django, flask, ...) or javascript to broaden the base of potential maintainers. 

> 
> However, dependence on github creates a duplicate repository for the source code. With 400+ activities, there is no mechanism in github to make the activities visible. Currently it may require searching 7 screens to find if an activity is there (unlike ASLO which has an effective search capability). 

ASLO is not a source code repository. It’s a convenience to end users. I know you think they should be one and the same, and in theory they could be, but I don’t necessarily see the benefit.
> 
> I am sympathetic to the desire to acquaint our users with git and the concept of version control. However, this approach limits the opportunity to those who have internet access (probably a minority of our users). 

I don’t see a reason why ASLO couldn’t simply be a front-end, pointing to .xo activity files which are mirrored elsewhere (even HTTP-accessible via Git/GitHub, or via a global CDN). That said, there is some value in hosting the activities directly on ASLO. There is also some risk, since, if ASLO goes offline, so does access to all activities.

> A more effective approach would be to determine how git could be installed in Sugar ( a git activity?) so that it can be used. Your book could then be used as a basis for helping our users learn to develop activities using version-control. In this way version control can be used locally by the developer prior to submitting an updated or new activity to ASLO (which may well involve a visit to an internet cafe). 

Git can absolutely be used locally (with branches, tags, etc) without external access to the Internet. It was designed to be use this way. That said, I don’t see why Git needs to be a sugar activity. It just needs to be a dependency of the development-specific Sugar packages (RPM/deb/etc)
> 
> Tony
> 
> Tony
> 
> 
> On 03/14/2017 03:39 AM, James Simmons wrote:
>> All,
>> 
>> I have been neglecting the manual Make Your Own Sugar Activities! ever since I first wrote it. However, I did manage to make one needed update in the laziest way possible. Since Sugar Labs has moved away from git.sugarlabs.org <http://git.sugarlabs.org/> in favor of GitHub since I wrote the version control chapter I have added the following note to that chapter:
>> 
>> Important Note: When this chapter was written Sugar Labs was still using git.sugarlabs.org <http://git.sugarlabs.org/> as its code repository. While this still exists, the preferred repository is now https://github.com/ <https://github.com/>, using the sugarlabs organization. This chapter is still a reasonable introduction to using Git, but when you set up your project repository you should use the excellent instructions provided on GitHub instead of the Gitorious instructions provided here.
>> 
>> I hope this helps in some way.
>> 
>> James Simmons
>> 
>> 
>> 
>> _______________________________________________
>> Sugar-devel mailing list
>> Sugar-devel at lists.sugarlabs.org <mailto:Sugar-devel at lists.sugarlabs.org>
>> http://lists.sugarlabs.org/listinfo/sugar-devel <http://lists.sugarlabs.org/listinfo/sugar-devel>
> 
> 
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org <mailto:Sugar-devel at lists.sugarlabs.org>
> http://lists.sugarlabs.org/listinfo/sugar-devel <http://lists.sugarlabs.org/listinfo/sugar-devel>
> 
> 
> 
> 
> -- 
> Walter Bender
> Sugar Labs
> http://www.sugarlabs.org <http://www.sugarlabs.org/>
>  <http://www.sugarlabs.org/>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20170313/c30d062a/attachment.html>


More information about the Sugar-devel mailing list