[Sugar-devel] ASLO activities with no repository
Tony Anderson
tony_anderson at usa.net
Wed May 24 22:07:50 EDT 2017
James
Your steps a-f and the references seem based on the Developer Hub in
ASLO. In this procedure the developer does the first two steps. Step c
is an updated version number in activity.info. Step d is 'setup.py
dist_xo'. Step e depends on the Developer Hub, but can only be done by
the developer or someone authorized by the developer. The Developer Hub
puts the bundle in download.sugar.labs/activities. Step f is
accomplished by step d, there is no second copy.
In this process a new submission or version is vetted by a moderator
before being displayed by ASLO. This may explain the many activities
which display earlier versions of an activity. The later bundles were
not uploaded through the Developer Hub or released through the moderator.
This Developer Hub procedure does not require that the developer use a
version control system.
The intent is to replace the Developer Hub with procedures based on
github. The github procedure involves two independent contributors - the
developer who prepares the repository for release and the maintainer
that performs the functions you have described previously.
One major benefit is that the procedure described in reference four is
not necessary. Any authorized contributor has the permissions needed to
make changes to an activity and to prepare a new version. A maintainer
works with the developer to ensure the new version satisfies applicable
community standards and then to publish it to ASLO.
ASLOv3 displays the most recent version of an activity. This means the
only connection between github operations and ASLO is the installation
of a new bundle in download.sugarlabs.org/activities.
Tony
On 05/25/2017 08:19 AM, James Cameron wrote:
> Harm is done by creating a repository from a bundle, as I've already
> described.
>
> I don't see the point of yet again listing orphans. It never does any
> good. Better would be to adopt activities and maintain them.
>
> Creating a repository from a bundle is a last step in maintaining an
> activity.
>
> Please don't do it until you have done the previous steps;
>
> (a) activity testing,
>
> (b) update activity version,
>
> (c) tag activity release,
>
> (d) make a bundle,
>
> (e) upload to ASLO, and
>
> (f) for certain activities upload to download.sugarlabs.org.
The first of you references has nothing to do with orphaned activities
(which in my meaning are activities without a supporting repository).
The second is content-free.
The third has not been updated since May 2016. Hardly a source of
current information.
The fourth refers to the Developer Hub method of maintaining activities.
The intent is to replace the Development Hub with github.
>
> References:
>
> https://wiki.sugarlabs.org/go/Orphaned_Activities_Report
> https://wiki.sugarlabs.org/go/GoogleCodeIn2012/Sugar_orphan_status
> https://wiki.sugarlabs.org/go/Activity_Team/Activity_Status
> https://wiki.sugarlabs.org/go/Activity_Team/Policy_for_nonresponsive_maintainers
>
>
> On Wed, May 24, 2017 at 06:39:43PM +0800, Tony Anderson wrote:
>> You are correct, about 75% of the activities on ASLO have identified
>> repositories. Interestingly, there are 250 repositories on git.sugarlabs.org
>> 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.
>>
>> Tony
>>
>> 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 <[1]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 [2]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 [3]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 [4]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
>> [5]Sugar-devel at lists.sugarlabs.org
>> [6]http://lists.sugarlabs.org/listinfo/sugar-devel
>>
>> --
>> photo Gonzalo Odiard
>> Lider de proyecto
>> [7]tel.: 2081-6424 y 2082-0312 | [8][9]
>> www.trinom.io Av Calchaqui 4936ยท 2do Piso.
>> Quilmes
>> [10][f] [11][l]
>>
>>
>>
>> _______________________________________________
>> Sugar-devel mailing list
>> [12]Sugar-devel at lists.sugarlabs.org
>> [13]http://lists.sugarlabs.org/listinfo/sugar-devel
>>
>> References:
>>
>> [1] mailto:tony_anderson at usa.net
>> [2] http://github.com/sugarlabs
>> [3] http://activities.sugarlabs.org/
>> [4] http://download.sugarlabs.org/
>> [5] mailto:Sugar-devel at lists.sugarlabs.org
>> [6] http://lists.sugarlabs.org/listinfo/sugar-devel
>> [7] tel:tel.:+4210-7748
>> [8] http://www.trinom.io/
>> [9] http://www.trinom.io/
>> [10] http://www.facebook.com/trinomiosrl
>> [11] https://www.linkedin.com/company/trinom-io
>> [12] mailto:Sugar-devel at lists.sugarlabs.org
>> [13] http://lists.sugarlabs.org/listinfo/sugar-devel
>> _______________________________________________
>> Sugar-devel mailing list
>> Sugar-devel at lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>
More information about the Sugar-devel
mailing list