[Sugar-devel] Response in Re: you needed Assistance

[Tony Anderson]

Sugar has two separate components: Sugar OS and Sugar activities. I 
don't believe anyone believes that the source code for Sugar OS should 
be anywhare a developer wants. Developers are free and should develop on 
their own repository often on their own development machine. The goal of 
the development is to improve Sugar in a future release. When ready, the 
developer needs to upload the change to SugarLabs github repository 
(e.g. by a PR). Back in the day, a pull request was a signal that a 
change was proposed and that other developers should pause until the 
change was merged. In this method the pull request was made for a very 
short time before it was merged and developers were free to check their 
changes to see if they were affected. Many developments use this 
technique to manage continuous integration where at any moment a build 
can be made from the repository to make sure it does not have 
regressions and to test the new capability.

So there is never a requirement that a developer does their work on the 
SugarLabs github, but there is a requirement that all changes that go 
into a release be made there.

The same basic principal applies to the activities, but I believe that 
we should have a github.com/sugaractivities for repositories of Sugar 
activities. All releases of activities to ASLO should be made from the 
github/sugaractivities repostory by the Activity Team. The git 
procedures for activities should not be the same as for Sugar OS since 
the requirements are completely different.

For Sugar OS, the code in mulitple repositories must be integrated to 
make a release and the developers are working concurrently on changes 
for the next release. Testing also needs to be much more extensive 
(hence, the value of continuous integration, automated regression tests 
and so on.

Sugar activities are developed and released by individual activity. This 
means far less collaborative work on a specific activity - most fixes 
and development are done by individuals for that particular activity. 
Further, the cost of a mistake is minimal. First, it affects at most one 
activity. Second, the user has a ready fallback to the previous version 
and even the ability to fix the problem themselves since the activity 
contains all of the code.

Keeping the two separate, enables having different development 
procedures and safety checks.

Because of the confusion in implementation of github, we are in a 
situation that nearly two hundred activities with github repositories 
are unavailable to Ubuntu users of Sugar - wasting the effort of many 
GCI and GSOC contributors. Currently there are only 10 activities 
available for the Ubuntu Sugar. This is apparently the consequence of 
attempting to apply procedures appropriate and necessary for Sugar OS to 
the Sugar activities.

I really appreciate your raising these questions about the goal of your 
project.

Tony

On Saturday, 19 May, 2018 05:40 AM, James Cameron wrote:
> On Fri, May 18, 2018 at 11:14:45PM +0200, Bastien wrote:
>> Hi James,
>>
>> James Cameron <quozl at laptop.org> writes:
>>
>>> People have often said "we should migrate them all to GitHub", but as
>>> far as I can see the only _sensible_ justification is where pull
>>> requests are to be merged by multiple developers.
>> Another justification would be to help *discovery* of repositories by
>> potential contributors.
> Yes.  On the other hand we have too many already, and no lack of
> opportunities for potential contributors.
>
>> While I recognize enforcing a central authority is not good, there is
>> still value in encouraging people to use https://github.com/sugarlabs
>> which is what the Github button does on the homepage.
> Yes, sure, encourage.  But not to mandate.
>
> My practice is to fork newly discovered repositories into
> https://github.com/sugarlabs
>
> And then turn off Issues, Projects, Wiki features, only allow Merge
> commits.
>
> An example is yet another Sugar Labs related repository by a developer
> created outside Sugar Labs;
>
> https://github.com/amanharitsh123/sugarizer-school-box
>
> Forked to Sugar Labs;
>
> https://github.com/sugarlabs/sugarizer-school-box
>
> And appears to contain many similar commits to existing Sugar Labs
> repository from last year;
>
> https://github.com/sugarlabs/rpi23-gen-image
>
> GitHub as a confusion creation tool.
>