[Sugar-devel] critical vs pinned repositories, was New pull request reviewers; Rahul and Yash

[Tony Anderson]

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 
console.log statements in javascript. It is not able to show the source 
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 
Journal activity.

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 
version 6!

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

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

Tony




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
>     http://quozl.netrek.org/
>     _______________________________________________
>     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
>
>
>
> _______________________________________________
> 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/20180228/4dd168b8/attachment-0001.html>