[Sugar-devel] [sugarlabs/ajedrez-activity] Adding A Suitable License (#1)
James Cameron
quozl at laptop.org
Mon May 21 22:32:45 EDT 2018
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
--
James Cameron
http://quozl.netrek.org/
More information about the Sugar-devel
mailing list