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_ander...@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 >> >> 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. >> >> > _______________________________________________ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > -- [image: photo] *Gonzalo Odiard* Lider de proyecto tel.: <tel.:+4210-7748>2081-6424 y 2082-0312 | 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@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel