[Sugar-devel] ASLO activities with no repository
James Cameron
quozl at laptop.org
Wed May 24 02:29:30 EDT 2017
On Tue, May 23, 2017 at 11:23:25AM +0800, Tony Anderson wrote:
> Hi, James
>
> Thank for these details. I am trying to find out what the standards
> are for these repositories.
>
> Tony Forster contacted me by private email to let me know that
> textdungeon did not have a repository. Version 4 is version 3 with
> the removal of
>
> import simplejson
>
> which causes an activity to fail with python 2.7.
Both of these pieces of information should be in the commits; please
rewrite them.
Also, it should not be marked version 4 until you are ready to do the
later steps in the role of activity maintainer; tag a release, make a
bundle, and upload to ASLO. As it stands now, there is no version 4
bundle in ASLO, yet the repository contains a version 4.
> In summary, in making a repository:
>
> * the commits need
> --author
> --date
> --compiled files such as .pyc should be deleted
> *git history should show each available version when created
> from a bundle
> *delete MANIFEST
The delete of MANIFEST and the GTK+ 3 porting should be commits made
after the commit of the latest ASLO version; not including any later
version you release from git.
> *add a .gitignore file (I understand this to be the same for all
> activities)
No, it won't be the same. It may have some patterns that are common.
It should have patterns for any files that may be created by running
or building the source.
> Regarding thoughts:
> b) how is an installed activity to work without these files
> in the bundle? How is source code for object files kept in the
> repository (e.g. box2d)?
It will work mysteriously. How and where source code is kept is up to
the activity author. My point is that you cannot trust the activity
author to have included source, and so a git repository built from the
bundle may end up being less useful for source control purposes.
> c) this is the goal. However, how do you do this for an
> activity for which there is no repository?
Do this carefully and with the appropriate social license; as part of
taking on activity maintenance role for an activity.
What Walter said, I agree with; paraphrasing now; creating a
repository from a bundle is a last resort action deep inside a long
process of maintaining an activity, which also includes upgrading it
to GTK+ 3, testing, and making a release.
It isn't something to do first on github.com/sugarlabs
> d) I don't understand you here. Any developers will see an
> activity with a link to a repository. How is that confusing?
Because the repository was built from the bundle, instead of the
bundle built from the repository.
> e) A repository provides a standard way to document problems
> that prevent the activity from working. Many activities in github
> may not work at a given time in the development, maintenance
> cycle. This has no effect until the bundle is released to ASLO. We
> have a fact that there are many (about one-half) bundles in ASLO
> that do not work. The best I can do is test and write an issue as to
> why they don't work. As volunteers get time, they can address the
> issues.
Where standard ways to document problems go against code quality and
maintenance in the project as a whole, then the latter should win.
> I am not a 'maintainer' on ASLO. This permission would be
> helpful.
I was speaking of being an activity maintainer, rather than only
developer status on activities.sugarlabs.org.
The role of an activity maintainer is to accept changes from others,
test the activity, iterate with fixes, update version, tag a release,
make a bundle, upload to ASLO, upload to download.sugarlabs.org, and
field any questions that arise.
I'd like to assess your capability in all those steps before giving
you any additional permissions on ASLO. On the other hand, I can't
give you any additional permissions on ASLO because I don't have them
myself. I'm not the one to convince on that.
--
James Cameron
http://quozl.netrek.org/
More information about the Sugar-devel
mailing list