[Sugar-devel] [sugarlabs/ajedrez-activity] Adding A Suitable License (#1)
Tony Anderson
tony at olenepal.org
Mon May 21 22:08:36 EDT 2018
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'.
<https://github.com/sugarlabs/sugar-docs/blob/master/src/contributing.md#modifying-activities>Modifying
Activities
/Most activity repositories can be found in our //GitHub
//|sugarlabs|//organizatio/n <https://github.com/sugarlabs>. 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
//activities.sugarlabs.org app store
<https://activities.sugarlabs.org/>//, or the //Activity page on
wiki.sugarlabs.org <https://wiki.sugarlabs.org/go/Activity>//, or our
deprecated //gitorious instance <https://git.sugarlabs.org/>//. /*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 //Write your own Sugar desktop activity
<https://github.com/sugarlabs/sugar-docs/blob/master/src/desktop-activity.md>//,
or //Write your own Sugar web activity
<https://github.com/sugarlabs/sugar-docs/blob/master/src/web-activity.md>//,
then make a new repository in your GitHub account, put the source code
in it, then ask the //systems@ list
<https://lists.sugarlabs.org/listinfo/systems>//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 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 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.
<https://github.com/sugarlabs/sugar-docs/blob/master/src/contributing.md#checklist---anyone>Checklist
- anyone
*
///make a fork and clone it, (clone seems sufficient) Generally,
developers are likely to clone to their own laptop and work there).
/
* /check if what you want to change is available already in any other
branches or forks - /*n**o*, 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.
*
/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./
/
*
///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.
*
///if your changes affect translatable strings; regenerate the POT
file, with //|python setup.py genpot|//,/ this would seem desirable
for any new version./
/
*
/make a branch, one or more commits, and a pull request, see
//Workflow
<https://github.com/sugarlabs/sugar-docs/blob/master/src/contributing.md#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
/
*
///check version of latest bundle release in
//activities.sugarlabs.org <https://activities.sugarlabs.org/>//, /Yes/
/
*
///check version of latest tarball release in
//download.sugarlabs.org/sources/sucrose/fructose/
<https://download.sugarlabs.org/sources/sucrose/fructose/>//or
//download.sugarlabs.org/sources/honey/
<https://download.sugarlabs.org/sources/honey/>//, /I really don't
know what a tarball has to do with Sugar activities/
/
*
///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?
//
*
/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.
*
/look for commmits after any of these, in either;/
//
o ///master branch of repository at sugarlabs,/
o ///any other branches,/
o ///any other forks,/
o ///orphaned repositories with the same //|bundle_id|//value,
using GitHub or Google Search,/
o ///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.
//
* //
///review and merge all pull requests, /No, not consistent with the
procedure above.
//
*
/apply all desired commits, making pull requests if review is
needed, /No, not consistent with the procedure above.
//
*
///apply all //translation.sugarlabs.org
<https://translate.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./
/
*
/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
//
*
/notify our translation-community manager @leonardcj /The
translation community should be on systems at lists.sugarlabs.org and
expect notification there.
*
/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./
//
*
/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./
/
//
* //
///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.
//
*
///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?
//
*
/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
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.
>
> https://www.gtk.org/
> https://en.wikipedia.org/wiki/GTK%2B
>
> The list of tasks for an activity maintainer is in
> 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]http://git.sugarlabs.org/ceibal-chess
>> or [4]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]
>> 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] https://github.com/yashagrawal3
>> [2] https://github.com/tony37
>> [3] http://git.sugarlabs.org/ceibal-chess
>> [4] https://github.com/alesegovia/ceibal-chess
>> [5] https://github.com/alesegovia
>> [6] https://translate.sugarlabs.org/
>> [7] https://github.com/alesegovia
>> [8] https://github.com/sugarlabs/ajedrez-activity/pull/1#issuecomment-390598392
>> [9] https://github.com/notifications/unsubscribe-auth/AAULkuMzgWLw80NHUNFSQy2p1XR95zgxks5t0oSUgaJpZM4Q5vl7
>> _______________________________________________
>> Sugar-devel mailing list
>> Sugar-devel at lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20180522/7189d08b/attachment-0001.html>
More information about the Sugar-devel
mailing list