[Sugar-devel] [sugarlabs/ajedrez-activity] Adding A Suitable License (#1)
Tony Anderson
tony at olenepal.org
Tue May 22 03:57:13 EDT 2018
I have already done it since i am not burdened by the process you impose.
On Tuesday, 22 May, 2018 12:03 PM, James Cameron wrote:
> The situation of unreleased yet ported activities is not a consequence
> of process, but of missing-in-action activity maintainers, and porting
> by GCI and GSoC.
>
> Your choice not to contribute your time for this is noted.
>
> It is a tempting move; I could simplify my work by focusing on
> maintaining activities for laptop production rather than share with
> you and others. Yes, perhaps that's what I'll do once the commit rate
> by others falls below 10% of mine.
>
> On Tue, May 22, 2018 at 11:51:16AM +0800, Tony Anderson wrote:
>> 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.
>>
>> Tony
>>
>> 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
>> _______________________________________________
>> 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