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 <qu...@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.
_______________________________________________
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
