[Sugar-devel] ASLO activities with no repository

[Tony Anderson]

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.
>