[Sugar-devel] critical vs pinned repositories, was New pull request reviewers; Rahul and Yash
tony_anderson at usa.net
Tue Feb 27 23:57:05 EST 2018
This thread illustrates the crazy situation we have put ourselves in.
Now we don't use github because we have too many repositories.
The simple solution is to separate repositories into a Sugar collection
and an Activity collection. The use of fructose (and honey,...) should
be deprecated. The terms have no meaning and are confusing. Can you
imagine the user launching the chat-fructose.activity (not to mention
translating 'fructose' to 100+ languages). Searching 300+ activities is
not necessary if they are sorted alphabetically (abacus.activity,
write.activity) and would be made easier if the activity names in ASLO
matched the repostory names.
The repositories in Sugar should be ones required for a build. A build
requires co-ordinated use of multiple repositories. Activities should be
independent of each other and of Sugar builds. The maker of a build
selects the activities to include in the build from those released.
Browse illustrates the problem with using common dependencies. Now it is
critical to use the Browse version which works with the right build.
This is contrary to the spirit of activities - that Sugar exists to
provide the execution environment for activities. Meanwhile, the
functionality of Browse becomes increasingly impaired. For example,
Browse cannot download or resume html pages. It does not have
configuration capabilities. A 404 error triggers a google search even
when the connection is to a school server. It is not able to display
code of a web page. It is not capable of saving a web page in the
Journal (it saves urls of open tabs which is normally useless and
consumes time discovering that the XO is not online).
Meanwhile, moving development support to github is making it more
difficult for users to modify their own installation. First, we chose
'view source' which suggests 'look but don't touch'. Then we wrapped
Python programming in pippy where a user can create an activity by pippy
magic. This, of course, hides the process from the user -- similar to
the effect of using Dreamweaver to create html/css. Now we have taken
development support away from the user who does not have ready internet
access (i.e. more than half our users).
Tomorrow I am scheduled to give a class to secondary school students on
programming. The students are already capable of using the Terminal
activity to navigate and manage the XO file system. Generally I
encourage them to use the Documents folder since it is visible in the
I plan to start with the Hello World activity. The repository for this
activity is hello-world-fork-master - this for the activity intended to
illustrate the simplest possible activity!!! To display 'Hello World!'
on the screen takes 42 lines of python code. The hello-world-fork-master
repository is a conversion of the original to gtk3 but continues to be
I have moved the toolbar related code to a separate file - toolbar.py.
This file is imported into activity.py. This reduces the number of lines
from 42 to 10. This is version 7.
More importantly, this activity is a useful template for user-developed
activities. Al Sweigart has written three books on Python programming
for children and has given them a Creative Commons license! My plan for
the class is to show the students how to make Al Sweigart's examples
into Sugar activities by copying the hello-world.activity to
guessing-game.activity and updating activity.info in the new activity.
Then the students can copy and paste their code into activity.py.
None of the programs in the Al Sweigart's first two books use GTK (only
print and raw_input). Naturally this is a problem for a Sugar activity
which displays print statements in the log and requires gtk to display
text on the screen. However, this is a learning opportunity for the
I truly wish some of this community effort and ingenuity were applied to
making Sugar a better educational environment, giving our users the
opportunity to explore and create rather than restricting it to elite
On Wednesday, 28 February, 2018 08:34 AM, Walter Bender wrote:
> On Tue, Feb 27, 2018 at 10:02 PM, James Cameron <quozl at laptop.org
> <mailto:quozl at laptop.org>> wrote:
> My list of critical repositories was on a thread focused on Sugar
> desktop and Python activity code review. It is less relevant for
> Sugar Labs as a whole.
> The mismatch at heart is GitHub's scalability of features for large
> open source projects with many repositories. We have 292 at the
> moment. Most are orphaned or abandoned. Using search is critical.
> Once a developer is familiar with our repository layout, the problem
> disappears for them. Does our ramp-up documentation explain well
> enough? I don't think I've heard many "where is X?" questions.
> We could waste a lot of time moving repositories around to meet
> consistent naming standards; I'd like to see reasoned benefit before
> doing that.
> I recently changed the pinned repositories. I'd have pinned Sugarizer
> and Music Blocks, but they are both being developed outside Sugar Labs
> on GitHub personal accounts. That's why I've got Browse and Turtle
> Art pinned.
> The reason Turtle Blocks and Music Blocks are still hosted in my
> personal repo is because we have had a backlog on sysadmin support, it
> has not been practical to host projects on the Sugar Labs servers.
> Using github.io <http://github.io> makes things pretty painless. But
> because we have not yet set up a github,io presence for Sugar Labs, so
> I haven't moved the repos. I'll try to finally wrap my head around
> what sugarlabs.github.io <http://sugarlabs.github.io> might look like
> and make some suggestions on this list.
> We could also waste a lot of time on dashboards or other
> meta-development. If we have a volunteer to do that, great, but I'm
> not putting my hand up.
> Repositories containing submodules for a collection of activities
> might be interesting, but it brings a new problem; maintenance of the
> repository in the face of ongoing change in the submodules. We've had
> to back away from submodules in Browse because of repeating bugs where
> a downstream used a GitHub release tag instead of our tarball.
> James Cameron
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> <mailto:Sugar-devel at lists.sugarlabs.org>
> Walter Bender
> Sugar Labs
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Sugar-devel