[Sugar-devel] ASLO activities with no repository

[Gonzalo Odiard]

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>
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 at 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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20170524/17fe74cb/attachment-0001.html>