<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> </head> <body text="#000000" bgcolor="#FFFFFF"> 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'. <h2><a id="user-content-modifying-activities" class="anchor" href="https://github.com/sugarlabs/sugar-docs/blob/master/src/contributing.md#modifying-activities"><svg class="octicon octicon-link" viewBox="0 0 16 16" width="16" height="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Modifying Activities</h2> Most activity repositories can be found in our <a href="https://github.com/sugarlabs">GitHub <code>sugarlabs</code> organization</a>. An alternative fact. At present about 20% are there. (198/514). A few activity repositories are somewhere else; read the <code>activity/activity.info</code> file, check the metadata on the <a href="https://activities.sugarlabs.org/" rel="nofollow">activities.sugarlabs.org app store</a>, or the <a href="https://wiki.sugarlabs.org/go/Activity" rel="nofollow">Activity page on wiki.sugarlabs.org</a>, or our deprecated <a href="https://git.sugarlabs.org/" rel="nofollow">gitorious instance</a>. 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 <a href="https://github.com/sugarlabs/sugar-docs/blob/master/src/desktop-activity.md">Write your own Sugar desktop activity</a>, or <a href="https://github.com/sugarlabs/sugar-docs/blob/master/src/web-activity.md">Write your own Sugar web activity</a>, then make a new repository in your GitHub account, put the source code in it, then ask the <a href="https://lists.sugarlabs.org/listinfo/systems" rel="nofollow">systems@ list</a> to move it to the GitHub <code>sugarlabs</code> organization. Excellent. This should also be the model for new versions of an activity. This is a workable procedure where <a class="moz-txt-link-abbreviated" href="mailto:systems@lists.sugarlabs.org">systems@lists.sugarlabs.org</a> 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 <a class="moz-txt-link-abbreviated" href="mailto:systems@lists.sugarlabs.org">systems@lists.sugarlabs.org</a> 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. <h3><a id="user-content-checklist---anyone" class="anchor" href="https://github.com/sugarlabs/sugar-docs/blob/master/src/contributing.md#checklist---anyone"><svg class="octicon octicon-link" viewBox="0 0 16 16" width="16" height="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Checklist - anyone</h3> <ul class="contains-task-list"> <li class="task-list-item"> <input id="" disabled="disabled" class="task-list-item-checkbox" type="checkbox"> make a fork and clone it, (clone seems sufficient) Generally, developers are likely to clone to their own laptop and work there). </li> <li class="task-list-item"><input id="" disabled="disabled" class="task-list-item-checkbox" type="checkbox"> 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. </li> <li class="task-list-item"> <input id="" disabled="disabled" class="task-list-item-checkbox" type="checkbox"> 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. </li> <li class="task-list-item"> <input id="" disabled="disabled" class="task-list-item-checkbox" type="checkbox"> 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. </li> <li class="task-list-item"> <input id="" disabled="disabled" class="task-list-item-checkbox" type="checkbox"> if your changes affect translatable strings; regenerate the POT file, with <code>python setup.py genpot</code>, this would seem desirable for any new version. </li> <li class="task-list-item"> <input id="" disabled="disabled" class="task-list-item-checkbox" type="checkbox"> make a branch, one or more commits, and a pull request, see <a href="https://github.com/sugarlabs/sugar-docs/blob/master/src/contributing.md#workflow">Workflow</a> 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. </li> </ul> 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 <ul class="contains-task-list"> <li class="task-list-item"> <input id="" disabled="disabled" class="task-list-item-checkbox" type="checkbox"> check version of latest bundle release in <a href="https://activities.sugarlabs.org/" rel="nofollow">activities.sugarlabs.org</a>, Yes </li> <li class="task-list-item"> <input id="" disabled="disabled" class="task-list-item-checkbox" type="checkbox"> check version of latest tarball release in <a href="https://download.sugarlabs.org/sources/sucrose/fructose/" rel="nofollow">download.sugarlabs.org/sources/sucrose/fructose/</a> or <a href="https://download.sugarlabs.org/sources/honey/" rel="nofollow">download.sugarlabs.org/sources/honey/</a>, I really don't know what a tarball has to do with Sugar activities </li> <li class="task-list-item"> <input id="" disabled="disabled" class="task-list-item-checkbox" type="checkbox"> 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? </li> <li class="task-list-item"> <input id="" disabled="disabled" class="task-list-item-checkbox" type="checkbox"> correlate with <code>activity_version</code> metadata in <code>activity/activity.info</code>, 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. </li> <li class="task-list-item"> <input id="" disabled="disabled" class="task-list-item-checkbox" type="checkbox"> look for commmits after any of these, in either; <ul class="contains-task-list"> <li class="task-list-item"><input id="" disabled="disabled" class="task-list-item-checkbox" type="checkbox"> master branch of repository at sugarlabs,</li> <li class="task-list-item"><input id="" disabled="disabled" class="task-list-item-checkbox" type="checkbox"> any other branches,</li> <li class="task-list-item"><input id="" disabled="disabled" class="task-list-item-checkbox" type="checkbox"> any other forks,</li> <li class="task-list-item"><input id="" disabled="disabled" class="task-list-item-checkbox" type="checkbox"> orphaned repositories with the same <code>bundle_id</code> value, using GitHub or Google Search,</li> <li class="task-list-item"><input id="" disabled="disabled" class="task-list-item-checkbox" type="checkbox"> 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. </li> </ul> </li> <li class="task-list-item"> <input id="" disabled="disabled" class="task-list-item-checkbox" type="checkbox"> review and merge all pull requests, No, not consistent with the procedure above. </li> <li class="task-list-item"> <input id="" disabled="disabled" class="task-list-item-checkbox" type="checkbox"> apply all desired commits, making pull requests if review is needed, No, not consistent with the procedure above. </li> <li class="task-list-item"> <input id="" disabled="disabled" class="task-list-item-checkbox" type="checkbox"> apply all <a href="https://translate.sugarlabs.org" rel="nofollow">translation.sugarlabs.org</a> 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. </li> <li class="task-list-item"> <input id="" disabled="disabled" class="task-list-item-checkbox" type="checkbox"> regenerate the POT file using <code>python setup.py genpot</code>, review the changes, and commit, No. This was done by the contributor and was part of the commit </li> <li class="task-list-item"> <input id="" disabled="disabled" class="task-list-item-checkbox" type="checkbox"> notify our translation-community manager @leonardcj The translation community should be on <a class="moz-txt-link-abbreviated" href="mailto:systems@lists.sugarlabs.org">systems@lists.sugarlabs.org</a> and expect notification there. </li> <li class="task-list-item"> <input id="" disabled="disabled" class="task-list-item-checkbox" type="checkbox"> 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. </li> <li class="task-list-item"> <input id="" disabled="disabled" class="task-list-item-checkbox" type="checkbox"> write release notes for the NEWS file, change the <code>activity_version</code> metadata in <code>activity/activity.info</code>, commit, and <code>git tag</code> 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. </li> <li class="task-list-item"> <input id="" disabled="disabled" class="task-list-item-checkbox" type="checkbox"> 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. </li> <li class="task-list-item"> <input id="" disabled="disabled" class="task-list-item-checkbox" type="checkbox"> for activities that include a tarball release, or where Fedora or Debian packages may be made, create a tarball using <code>python setup.py dist_source</code>, 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? </li> <li class="task-list-item"> <input id="" disabled="disabled" class="task-list-item-checkbox" type="checkbox"> create bundle using <code>python setup.py dist_xo</code>, 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. </li> </ul> 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 <a class="moz-txt-link-abbreviated" href="mailto:systems@lists.sugarlabs.org">systems@lists.sugarlabs.org</a>. 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 <div class="moz-cite-prefix"> On Tuesday, 22 May, 2018 07:44 AM, James Cameron wrote: </div> <blockquote type="cite" cite="mid:20180521234412.GF19926@us.netrek.org"> <pre wrap="">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. <a class="moz-txt-link-freetext" href="https://www.gtk.org/">https://www.gtk.org/</a> <a class="moz-txt-link-freetext" href="https://en.wikipedia.org/wiki/GTK%2B">https://en.wikipedia.org/wiki/GTK%2B</a> The list of tasks for an activity maintainer is in <a class="moz-txt-link-freetext" href="https://github.com/sugarlabs/sugar-docs/blob/master/src/contributing.md#checklist---maintainer">https://github.com/sugarlabs/sugar-docs/blob/master/src/contributing.md#checklist---maintainer</a> 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: </pre> <blockquote type="cite"> <pre wrap="">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]<a class="moz-txt-link-freetext" href="http://git.sugarlabs.org/ceibal-chess">http://git.sugarlabs.org/ceibal-chess</a> or [4]<a class="moz-txt-link-freetext" href="https://github.com/alesegovia/ceibal-chess">https://github.com/alesegovia/ceibal-chess</a> □ 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] <a class="moz-txt-link-freetext" href="https://translate.sugarlabs.org">https://translate.sugarlabs.org</a> □ 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] <a class="moz-txt-link-freetext" href="https://github.com/yashagrawal3">https://github.com/yashagrawal3</a> [2] <a class="moz-txt-link-freetext" href="https://github.com/tony37">https://github.com/tony37</a> [3] <a class="moz-txt-link-freetext" href="http://git.sugarlabs.org/ceibal-chess">http://git.sugarlabs.org/ceibal-chess</a> [4] <a class="moz-txt-link-freetext" href="https://github.com/alesegovia/ceibal-chess">https://github.com/alesegovia/ceibal-chess</a> [5] <a class="moz-txt-link-freetext" href="https://github.com/alesegovia">https://github.com/alesegovia</a> [6] <a class="moz-txt-link-freetext" href="https://translate.sugarlabs.org/">https://translate.sugarlabs.org/</a> [7] <a class="moz-txt-link-freetext" href="https://github.com/alesegovia">https://github.com/alesegovia</a> [8] <a class="moz-txt-link-freetext" href="https://github.com/sugarlabs/ajedrez-activity/pull/1#issuecomment-390598392">https://github.com/sugarlabs/ajedrez-activity/pull/1#issuecomment-390598392</a> [9] <a class="moz-txt-link-freetext" href="https://github.com/notifications/unsubscribe-auth/AAULkuMzgWLw80NHUNFSQy2p1XR95zgxks5t0oSUgaJpZM4Q5vl7">https://github.com/notifications/unsubscribe-auth/AAULkuMzgWLw80NHUNFSQy2p1XR95zgxks5t0oSUgaJpZM4Q5vl7</a> </pre> </blockquote> <pre wrap=""> </pre> <blockquote type="cite"> <pre wrap="">_______________________________________________ Sugar-devel mailing list <a class="moz-txt-link-abbreviated" href="mailto:Sugar-devel@lists.sugarlabs.org">Sugar-devel@lists.sugarlabs.org</a> <a class="moz-txt-link-freetext" href="http://lists.sugarlabs.org/listinfo/sugar-devel">http://lists.sugarlabs.org/listinfo/sugar-devel</a> </pre> </blockquote> <pre wrap=""> </pre> </blockquote> </body> </html>