[Sugar-devel] [sugarlabs/ajedrez-activity] Adding A Suitable License (#1)

Tony Anderson tony at olenepal.org
Mon May 21 22:08:36 EDT 2018

You repeated that I destroyed something. Ignoring commits does not mean 
there was destruction. I apologize again for my ignorance of the fact 
that people were developing and maintaining activities in cyberspace.

Git history or no, the important point is to have working activities 
available to our users and prospective users. This is the vital role of 

My comment about + was, of course, that I see no improvement in GTK3 
over GTK2 but only the cost of its deliberately incompatible 
implementation. So far, it appears that Gimp has been unable to complete 
the port even though GTK was created as a toolkit for Gimp. They may 
skip GTK3 and start directly to GTK4.

I think your contributing document is incomplete and needs to be 
modified. The most important point is that applying procedures necessary 
for Sugar OS development to activity developers is unnecessary overkill.

The Contributing section applies only to Sugar OS and ought not be 
applied to activities. Following are my comments on 'Modifying Activities'.


/Most activity repositories can be found in our //GitHub 
//|sugarlabs|//organizatio/n <https://github.com/sugarlabs>. An 
alternative fact.  At present about 20% are there. (198/514).

/A few activity repositories are somewhere else; read the 
//|activity/activity.info|//file, check the metadata on the 
//activities.sugarlabs.org app store 
<https://activities.sugarlabs.org/>//, or the //Activity page on 
wiki.sugarlabs.org <https://wiki.sugarlabs.org/go/Activity>//, or our 
deprecated //gitorious instance <https://git.sugarlabs.org/>//. /*No, 
*The starting point should be a clone of the repository on 
github/SugarLabs or the current version on ASLO if no repository is on 

/For new activities, see //Write your own Sugar desktop activity 
or //Write your own Sugar web activity 
then make a new repository in your GitHub account, put the source code 
in it, then ask the //systems@ list 
<https://lists.sugarlabs.org/listinfo/systems>//to move it to the GitHub 

Excellent. This should also be the model for new versions of an 
activity. This is a workable procedure where systems at lists.sugarlabs.org 
is manned by the Activity Team. So a typical procedure would be to clone 
an activity to a personal computer with Sugar. The developer makes 
changes such as a port to GTK3. During the port, the activity is 
launched and the log is checked to see why it is not starting. When the 
contributor has completed a new version it is pushed to the contributors 
github. The contributor sends an email to systems at lists.sugarlabs.org 
notifying the Activity Team that a new version is ready for release.

/After modifying an activity, a new release may be needed. Some 
activities have no maintainer, so you may need to be the maintainer for 
a short time./

The original model was that one person was responsible for an activity - 
but could bring on co-contributors. New versions were submitted to ASLO 
and after review released (normally by Walter Bender). However this 
model has changed. Activities in github are maintained by the community 
regardless of the original author or contributor - e.g ports to GTK3. A 
maintainer suggests someone dealing with an issue while a developer is 
adding a new feature. The distinction is not significant - all are 

      - anyone


    ///make a fork and clone it, (clone seems sufficient) Generally,
    developers are likely to clone to their own laptop and work there).

  * /check if what you want to change is available already in any other
    branches or forks - /*n**o*, the base for any change needs to be the
    activity master on github. If code is ready somewhere in cyberspace,
    it needs to be merged to the activity master to make a new version.

    /make and test your changes, /changes can be made in the Activities
    folder in Ubuntu or an XO Sugar. This process allows immediate
    testing of changes./


    ///if your changes add a new feature or will affect users; update
    the NEWS file, the README.md file, and the help-activity,/ when
    commiting a new version, there needs to be release notes (how has
    the new version improved on the previous version). The release notes
    need to be visible to a user of ASLO to help decide whether the
    update is needed.


    ///if your changes affect translatable strings; regenerate the POT
    file, with //|python setup.py genpot|//,/ this would seem desirable
    for any new version./


    /make a branch, one or more commits, and a pull request, see
    A mistake in a commit only affects that activity and has no
    downstream consequences. One of the benefits of git is that the bad
    commit can be easily removed. The procedure above is correct.

//Checklist - maintainer

The word maintainer should not be used in this context. The 
maintainer/developer is the contributor. This role belongs to the 
Activity Team


    ///check version of latest bundle release in
    //activities.sugarlabs.org <https://activities.sugarlabs.org/>//, /Yes/


    ///check version of latest tarball release in
    <https://download.sugarlabs.org/sources/honey/>//, /I really don't
    know what a tarball has to do with Sugar activities/


    ///check for a release version git tag, e.g. v34, /You don't say how
    this is done. (how is the tag committed. What is the difference
    between a tag and a commit message or a fork or a branch?


    /correlate with //|activity_version|//metadata in
    //|activity/activity.info|//,/ This is not metadata. This is the
    basis for naming the bundle produced by setup.py. Probably the
    meaning is that version in activity.info must be incremented from
    the previous version. Hopefully, the git procedure allows extraction
    of the code for a previous version so that reported problems can be


    /look for commmits after any of these, in either;/

      o ///master branch of repository at sugarlabs,/
      o ///any other branches,/
      o ///any other forks,/
      o ///orphaned repositories with the same //|bundle_id|//value,
        using GitHub or Google Search,/
      o ///deprecated repositories at git.sugarlabs.org,/ *No, no, no*.
        The github/Sugarlabs repository is the basis for release of
        activities. Any repositories in cyberspace are irrelevant and
        have not been released. There is no need for the Activity Team
        to ask the Russians or NSA if there is some later version somewhere.
  * //

    ///review and merge all pull requests, /No, not consistent with the
    procedure above.


    /apply all desired commits, making pull requests if review is
    needed, /No, not consistent with the procedure above.


    ///apply all //translation.sugarlabs.org
    <https://translate.sugarlabs.org>//changes, /This is a serious
    problem/./ Many of the 80 repositories in github now have unreleased
    mergers of po files which appear not to have been tested. However, a
    real test would be to execute the activity in each of the supported
    locales. When a new version of an activity is submitted, it is not
    possible to do this because the required new translations have not
    been done. Neither will they be done at any specific time in the
    future since there are possible translations required to over 100
    languages. There really needs to be a realistic procedure developed
    - provide the I18n team with the new pot, get a merge request from
    the team when some level of translations are ready for release,
    merge these translations to make a new version of the activity and
    release it. Perhaps a scheme with odd and even version numbers would
    help. New feature versions could have even numbers. When
    translations are available for that version, one could be released
    to ASLO with the odd version number. If two feature versions are
    released before a po version, the version could be incremented by 2./


    /regenerate the POT file using //|python setup.py genpot|//, review
    the changes, and commit, /No. This was done by the contributor and
    was part of the commit


    /notify our translation-community manager @leonardcj /The
    translation community should be on systems at lists.sugarlabs.org and
    expect notification there.


    /update the README.md file if necessary,//The item + 2 seems to
    cover this. The need is for the user to be able to see release notes
    before deciding whether to update to the new version./


    /write release notes for the NEWS file, change the
    //|activity_version|//metadata in //|activity/activity.info|//,
    commit, and //|git tag|//the version, /This should be expected of
    the contributor before submitting the new version. There needs to be
    a detailed procedure for the commit and git tag. The problem is to
    provide the release notes where the user can make a decision whether
    the update is needed./

  * //

    ///update the activity documentation in the help-activity
    repository, /No, if needed this is the responsibilty of the
    contributor. At the moment there is help documentation for 47
    activites of 514. The help activity is an activity. However, the
    documentation is part of the Sugarlabs web site. At the moment it is
    much more practical to leave the help activity out of this process
    except if a new version of the help activity itself is being submitted.


    ///for activities that include a tarball release, or where Fedora or
    Debian packages may be made, create a tarball using //|python
    setup.py dist_source|//, and upload tarball to
    download.sugarlabs.org using shell account, /I have no knowledge of
    what this is about - but I don't know how a contributor would know
    where Fedora or Debian packages may be made. Why does this matter
    for an activity?


    /create bundle using //|python setup.py dist_xo|//, test that it can
    be installed by Browse, and upload to activities.sugarlabs.org using
    developer account./ This absolutely needs to be done. The test with
    setup.py, installing with Browse is a task for the contributor. The
    'upload to activities.sugarlabs.org' task is the primary
    responsibility in this section and of the Activity Team. This
    neglect of this task makes about 80 activities which have been
    ported to GTK3 unavailable to our users.

In summary,

Activities are developed and maintained by community contributors. A 
contributor can be expected to develop a new version of an activity on 
their own computer offline. The availability of Sugar on Ubuntu makes 
this a particularly attractive development environment. When a 
contributor has completed and tested, the git repository is pushed to 
the contributors github account and an email message sent to 
systems at lists.sugarlabs.org. The Activity Team verifies the basics: the 
new version produces a bundle by setup.py, the version number has been 
incremented, the bundle can be installed by Browse, the activity 
launches and starts. Once verified the Activity Team installs the bundle 
in its addon id directory in ASLO and updates the addon interface. Any 
repository for an activity which is not in github/SugarLabs (or better 
github/SugarActivities) is invisible to the process. Any contributor 
intervention for an activity should start from the github repository, if 
any or from a bundle downloaded from ASLO, if not.


On Tuesday, 22 May, 2018 07:44 AM, James Cameron wrote:
> There were two repositories.  You destroyed, by ignoring, commits to
> those repositories.  You've done it several times now; but I'm not
> surprised, as you aren't an activity maintainer yet.
> GTK+ is the name to the toolkit according to both The GTK+ Project and
> Wikipedia.  It deserves a "+" because that's the name the authors
> used.  I'll continue to credit their work by using the proper name.
> https://www.gtk.org/
> https://en.wikipedia.org/wiki/GTK%2B
> The list of tasks for an activity maintainer is in
> https://github.com/sugarlabs/sugar-docs/blob/master/src/contributing.md#checklist---maintainer
> and already includes incrementing a version number.
> Translations should be merged to honour the work done by translators;
> it is the same activity, based on recursive comparison of files.
> I don't plan to make this activity available for Ubuntu Sugar, because
> it is in terrible shape.  If someone were to maintain it, then I'd be
> a bit more interested.
> On Tue, May 22, 2018 at 07:10:36AM +0800, Tony Anderson wrote:
>> I really wish you would be a bit more careful with the facts. There was no
>> repository for this activity, so it is impossible that i destroyed anything.
>> Why would you merge translations from one activity to another when neither has
>> been ported to GTK3?
>> Porting to GTK3 (no evidence that it deserves a +), should affect the wrapper
>> code and not the binary. Making this activity or gnuchess available for the
>> Ubuntu Sugar would be helpful.
>> A simple alternative is to install gnuchess on the Gnome desktop and then
>> prepare a simple wrapper from the HelloWorld activity (GTK3 version in the
>> repository). The wrapper would execute gnuchess in Sugar.
>> EndGame activity is a different animal as it teaches simple end games in chess.
>> I appreciate your including release in the set of tasks, something which has
>> not been done. One of your bullets should be to increment the version number.
>> Tony
>> On Monday, 21 May, 2018 05:10 PM, James Cameron wrote:
>>      [1]@yashagrawal3, you might defer this activity to later in your list,
>>      because it will be a huge time sink. This activity needs much more than a
>>      COPYING file. It needs;
>>        □ restoring the git history lost when [2]@tony37 created the repository
>>          from a bundle instead of using [3]http://git.sugarlabs.org/ceibal-chess
>>          or [4]https://github.com/alesegovia/ceibal-chess
>>        □ add license metadata in activity.info (which can be found in [5]
>>          @alesegovia's repository), along with a license for the embedded
>>          binary,
>>        □ removing the MANIFEST file,
>>        □ updating the embedded binary to the latest version and including other
>>          architectures; or adding a dependency that must be resolved before
>>          installing the activity.
>>        □ perhaps merging translations from the SimpleGNUChess activity on [6]
>>          https://translate.sugarlabs.org
>>        □ testing,
>>        □ porting to GTK+ 3,
>>        □ testing,
>>        □ release.
>>      [7]@alesegovia may have some ideas on how to proceed.
>>>>      You are receiving this because you were mentioned.
>>      Reply to this email directly, [8]view it on GitHub, or [9]mute the thread.*
>> References:
>> [1] https://github.com/yashagrawal3
>> [2] https://github.com/tony37
>> [3] http://git.sugarlabs.org/ceibal-chess
>> [4] https://github.com/alesegovia/ceibal-chess
>> [5] https://github.com/alesegovia
>> [6] https://translate.sugarlabs.org/
>> [7] https://github.com/alesegovia
>> [8] https://github.com/sugarlabs/ajedrez-activity/pull/1#issuecomment-390598392
>> [9] https://github.com/notifications/unsubscribe-auth/AAULkuMzgWLw80NHUNFSQy2p1XR95zgxks5t0oSUgaJpZM4Q5vl7
>> _______________________________________________
>> 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/20180522/7189d08b/attachment-0001.html>

More information about the Sugar-devel mailing list