[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.
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
>
More information about the Sugar-devel
mailing list