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

Tony Anderson tony_anderson at usa.net
Mon May 21 23:51:16 EDT 2018

Naturally it is easy to comment on what you haven't read.

When you propose a change to practice - it certainly isn't going to 
match. Current practice finds us with almost 80 activities which have
been ported to GTK3 and which are not available to users via ASLO.

I am an activity maintainer - sadly not to benefit SugarLabs but for 
deployments with a school server. However, the result will be to make 
these activities available for 1000+ users.


On Tuesday, 22 May, 2018 10:32 AM, James Cameron wrote:
> TL;DR.  Too long, didn't read.
> What I did read doesn't match with the situation and practice; and
> you're not an activity maintainer, so I don't think you know what you
> are talking about.
> Development process is optimised for activity maintainers, not
> integrators and certainly not users.
> If any activity maintainers have the time to stop maintaining
> activities and respond to these points from Tony, please let me know
> what you think.
> On Tue, May 22, 2018 at 10:08:36AM +0800, Tony Anderson wrote:
>> 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 ASLO.
>> 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'.
>> [1]Modifying Activities
>> Most activity repositories can be found in our [2]GitHub sugarlabs organization
>> . 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 [3]activities.sugarlabs.org app store, or the
>> [4]Activity page on wiki.sugarlabs.org, or our deprecated [5]gitorious instance
>> . 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 github.
>> For new activities, see [6]Write your own Sugar desktop activity, or [7]Write
>> your own Sugar web activity, then make a new repository in your GitHub account,
>> put the source code in it, then ask the [8]systems@ list to move it to the
>> GitHub sugarlabs organization.
>> Excellent. This should also be the model for new versions of an activity. This
>> is a workable procedure where [9]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 [10]
>> 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 contributors.
>> [11]Checklist - anyone
>>    • [12][ ] make a fork and clone it, (clone seems sufficient) Generally,
>>      developers are likely to clone to their own laptop and work there).
>>    • [13][ ] check if what you want to change is available already in any other
>>      branches or forks - no, 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.
>>    • [14][ ] 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.
>>    • [15][ ] 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.
>>    • [16][ ] if your changes affect translatable strings; regenerate the POT
>>      file, with python setup.py genpot, this would seem desirable for any new
>>      version.
>>    • [17][ ] make a branch, one or more commits, and a pull request, see [18]
>>      Workflow below. Wrong! 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
>>    • [19][ ] check version of latest bundle release in [20]
>>      activities.sugarlabs.org, Yes
>>    • [21][ ] check version of latest tarball release in [22]
>>      download.sugarlabs.org/sources/sucrose/fructose/ or [23]
>>      download.sugarlabs.org/sources/honey/, I really don't know what a tarball
>>      has to do with Sugar activities
>>    • [24][ ] 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?
>>    • [25][ ] 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 reproduced.
>>    • [26][ ] look for commmits after any of these, in either;
>>        □ [27][ ] master branch of repository at sugarlabs,
>>        □ [28][ ] any other branches,
>>        □ [29][ ] any other forks,
>>        □ [30][ ] orphaned repositories with the same bundle_id value, using
>>          GitHub or Google Search,
>>        □ [31][ ] 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.
>>    • [32][ ] review and merge all pull requests, No, not consistent with the
>>      procedure above.
>>    • [33][ ] apply all desired commits, making pull requests if review is
>>      needed, No, not consistent with the procedure above.
>>    • [34][ ] apply all [35]translation.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.
>>    • [36][ ] 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
>>    • [37][ ] notify our translation-community manager @leonardcj The translation
>>      community should be on [38]systems at lists.sugarlabs.org and expect
>>      notification there.
>>    • [39][ ] 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.
>>    • [40][ ] 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.
>>    • [41][ ] 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.
>>    • [42][ ] 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?
>>    • [43][ ] 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 [44]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.
>> Tony
>> 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.
>>      [45]https://www.gtk.org/
>>      [46]https://en.wikipedia.org/wiki/GTK%2B
>>      The list of tasks for an activity maintainer is in
>>      [47]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][48]http://git.sugarlabs.org/ceibal-chess
>>                  or [4][49]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]
>>                  [50]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] [51]https://github.com/yashagrawal3
>>          [2] [52]https://github.com/tony37
>>          [3] [53]http://git.sugarlabs.org/ceibal-chess
>>          [4] [54]https://github.com/alesegovia/ceibal-chess
>>          [5] [55]https://github.com/alesegovia
>>          [6] [56]https://translate.sugarlabs.org/
>>          [7] [57]https://github.com/alesegovia
>>          [8] [58]https://github.com/sugarlabs/ajedrez-activity/pull/1#issuecomment-390598392
>>          [9] [59]https://github.com/notifications/unsubscribe-auth/AAULkuMzgWLw80NHUNFSQy2p1XR95zgxks5t0oSUgaJpZM4Q5vl7
>>          _______________________________________________
>>          Sugar-devel mailing list
>>          [60]Sugar-devel at lists.sugarlabs.org
>>          [61]http://lists.sugarlabs.org/listinfo/sugar-devel
>> References:
>> [1] https://github.com/sugarlabs/sugar-docs/blob/master/src/contributing.md#modifying-activities
>> [2] https://github.com/sugarlabs
>> [3] https://activities.sugarlabs.org/
>> [4] https://wiki.sugarlabs.org/go/Activity
>> [5] https://git.sugarlabs.org/
>> [6] https://github.com/sugarlabs/sugar-docs/blob/master/src/desktop-activity.md
>> [7] https://github.com/sugarlabs/sugar-docs/blob/master/src/web-activity.md
>> [8] https://lists.sugarlabs.org/listinfo/systems
>> [9] mailto:systems at lists.sugarlabs.org
>> [10] mailto:systems at lists.sugarlabs.org
>> [11] https://github.com/sugarlabs/sugar-docs/blob/master/src/contributing.md#checklist---anyone
>> [18] https://github.com/sugarlabs/sugar-docs/blob/master/src/contributing.md#workflow
>> [20] https://activities.sugarlabs.org/
>> [22] https://download.sugarlabs.org/sources/sucrose/fructose/
>> [23] https://download.sugarlabs.org/sources/honey/
>> [35] https://translate.sugarlabs.org/
>> [38] mailto:systems at lists.sugarlabs.org
>> [44] mailto:systems at lists.sugarlabs.org
>> [45] https://www.gtk.org/
>> [46] https://en.wikipedia.org/wiki/GTK%2B
>> [47] https://github.com/sugarlabs/sugar-docs/blob/master/src/contributing.md#checklist---maintainer
>> [48] http://git.sugarlabs.org/ceibal-chess
>> [49] https://github.com/alesegovia/ceibal-chess
>> [50] https://translate.sugarlabs.org/
>> [51] https://github.com/yashagrawal3
>> [52] https://github.com/tony37
>> [53] http://git.sugarlabs.org/ceibal-chess
>> [54] https://github.com/alesegovia/ceibal-chess
>> [55] https://github.com/alesegovia
>> [56] https://translate.sugarlabs.org/
>> [57] https://github.com/alesegovia
>> [58] https://github.com/sugarlabs/ajedrez-activity/pull/1#issuecomment-390598392
>> [59] https://github.com/notifications/unsubscribe-auth/AAULkuMzgWLw80NHUNFSQy2p1XR95zgxks5t0oSUgaJpZM4Q5vl7
>> [60] mailto:Sugar-devel at lists.sugarlabs.org
>> [61] http://lists.sugarlabs.org/listinfo/sugar-devel
>> _______________________________________________
>> Sugar-devel mailing list
>> Sugar-devel at lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel

More information about the Sugar-devel mailing list