[Sugar-devel] ASLO activities with no repository

Tony Anderson tony_anderson at usa.net
Wed May 24 06:39:43 EDT 2017

You are correct, about 75% of the activities on ASLO have identified 
repositories. Interestingly, there are 250 repositories on 
which may be activity projects with no corresponding bundle on ASLO.

I reviewed the Pootle list yesterday and recorded the url to each 
repository in the spreadsheet.

So the question is, when to go for the last resort? No harm is done by 
creating a repository from the bundle.

Since I am traveling in the next two weeks, I doubt there will be time 
to work on this until after that. If the community wishes I can then 
create a wiki page with the list of these orphans. It would be 
essentially the list of 224 minus about 20 where repositories have been 
identified by you and others.


On 05/24/2017 06:06 PM, Gonzalo Odiard wrote:
> Most activities certainly had a repository.
> I fully agree with creating repositories from bundles only as a last 
> resource.
> Probably is better create a wiki page based in the  Pootle page and 
> add all the project without a known repository,
> and other can help to find the most updated repository.
> Gonzalo
> On Wed, May 24, 2017 at 6:22 AM, Tony Anderson <tony_anderson at usa.net 
> <mailto:tony_anderson at usa.net>> wrote:
>     You repeat that a repository exists before an activity bundle. I
>     have listed 200 activities (about 25%) of the activities
>     on ASLO that probably do not have one. Further, if the repository
>     cannot be found - we need to go ahead with what we have.
>     No matter how the working directory is created, git init should be
>     applied to create a repository and subsequent changes documented.
>     If there is a problem with an activity, the github repository
>     should have an issue documenting the problem pending finding the
>     resources to fix it.
>     Tony
>     On 05/24/2017 02:29 PM, James Cameron wrote:
>         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
>         <http://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
>         <http://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 <http://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.
>     _______________________________________________
>     Sugar-devel mailing list
>     Sugar-devel at lists.sugarlabs.org
>     <mailto:Sugar-devel at lists.sugarlabs.org>
>     http://lists.sugarlabs.org/listinfo/sugar-devel
>     <http://lists.sugarlabs.org/listinfo/sugar-devel>
> -- 
> photo 	
> *Gonzalo Odiard*
> Lider de proyecto
> tel.: <tel:tel.:+4210-7748>2081-6424 y 2082-0312 | www.trinom.io 
> <http://www.trinom.io/>Av Calchaqui 4936ยท 2do Piso. Quilmes
> <http://www.facebook.com/trinomiosrl> 
> <https://www.linkedin.com/company/trinom-io>
> _______________________________________________
> 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/20170524/9d69b666/attachment.html>

More information about the Sugar-devel mailing list