[Sugar-devel] ASLO activities with no repository

[Tony Anderson]

I appreciate this new information.

You have described the activity maintainer:

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


The developer in this description provides the changes.

My model is slightly different:

An activity needs to be ported to GTK+3. The developer makes a clone and 
makes the necessary changes with one or more commits. When the task is 
complete, the developer requests the maintainer to publish the new 
activity version.

The maintainer works with the developer as you did with Utkarsh on PR 
#327 to ensure that the new version is ready for release. When that is 
done, the maintainer bundles the activity and adds it to 
download.sugarlabs.org/activities. ASLO then displays that version.

"No, you're wrong, and you've got this wrong repeatedly, so please pay 
attention; for download.sugarlabs.org/sources there is a tar file not an 
xo file, and the setup.py argument is different; dist_source."

The bundles are stored in download.sugarlabs.org/activities. This is the 
source from which ASLO downloads bundles. The source directory along 
with others there have nothing to do with ASLO.

"There is a simpler explanation; the bug in ASLO, which was fixed 
recently; and now the latest version released to ASLO is displayed."

  Great! Thanks to you and whoever else helped to fix that problem."

"I'll continue to disagree until you've shown further understanding of 
the process. If you break the process too much, then I'll bypass it as 
I've already had to do for the existing process breakage; which is why 
we have several point releases of activities in OLPC OS; like Terminal 
44.1, Wikipedia 38.2, Pippy 70.2, Maze 26.1, GetBooks 16.2, Gears 6.2, 
Fototoon 22.1, FindWords 3.1, and Browse 200.1. All due to absence of 
maintenance. Sebastian was quite right to call out the problem yet 
again, and your insistence on process change seems likely to make the 
problem worse."

You have your own requirements which are apparently not now supported by 
ASLO. The ASLO process was not broken, you just chose not to use it.

I am working with Sam Cantaro to help mentor the ASLOv3 project. The 
goal of this project is to make things better. It needs support from the 
community in terms of requirements and things to avoid.

An important simplification for this project is to separate the 
'Developer Hub' functionality so that it does not need to be replicated. 
The intent is to replace it with a process based on github.

Please help us to understand what risks you see in ASLOv3 and with 
trying to make sure that every activity published on ASLO has a 
corresponding git repository.

Sam and I are in agreement that the information displayed should come 
from the bundles and not from a database as at present. This will 
require defining standards for the bundle different from those now in 
place. I expect there will need to be a script to verify that a new 
activity version has this information, possibly run as a part of 
bundlebuilder.

Tony

On 05/25/2017 03:06 PM, James Cameron wrote:
> On Thu, May 25, 2017 at 10:07:50AM +0800, Tony Anderson wrote:
>> James
>>
>> Your steps a-f and the references seem based on the Developer Hub in
>> ASLO.
> No, that's coincidence.  The steps predate that description, and were
> part of OLPC software development process for activities before Sugar
> Labs began.
>
>> 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.
> Fine so far, but the better term is activity maintainer.
>
>> Step f is accomplished by step d, there is no second copy.
> No, you're wrong, and you've got this wrong repeatedly, so please pay
> attention; for download.sugarlabs.org/sources there is a tar file not
> an xo file, and the setup.py argument is different; dist_source.
>
> A reasonable mistake for you to make; you conflated the multiple
> purposes of download.sugarlabs.org, and you're not an activity
> maintainer, or you'd have known by now.
>
> For a given activity the tar file is not the same as the xo file,
> though there are plenty of similarities.  In particular the xo file
> has the locale directory and the tar file does not, but there may be
> other differences where the developer has added dist_xo or dist_source
> targets to setup.py.  Help and TurtleArt have done that, and there are
> likely more.
>
> And the above, by the way, are reasons why a zip or tar from GitHub
> won't be sufficient.
>
> Please read and understand the code in
> src/sugar3/activity/bundlebuilder.py
>
>> In this process a new submission or version is vetted by a moderator
>> before being displayed by ASLO.
> Yes, that point you make is true, but has no bearing on the
> discussion, because as we agreed with Samuel it will be removed.
>
> There will be no moderation apart from GitHub pull request and commit
> review for activities maintained there.
>
>> This may explain the many activities which display earlier versions
>> of an activity.
> There is a simpler explanation; the bug in ASLO, which was fixed
> recently; and now the latest version released to ASLO is displayed.
>
>> The later bundles were not uploaded through the Developer Hub or
>> released through the moderator.
> Yes, in many cases because we the activity maintainers didn't want
> the new version to be offered through ASLO.  An example is Browse-200,
> which in the state it is in if offered would break Browse entirely and
> not be recoverable without using Terminal.
>
> Also because without access to ASLO my point releases were not made
> there; instead delivered as updates to OLPC OS laptops through the
> microformat software update, which my download.laptop.org logs tell me
> is quite popular.
>
>> This Developer Hub procedure does not require that the developer use
>> a version control system.
> Yes, that's good.  Lower barrier to participation.  The GSoC and GCI
> students really struggle with git, so anything we can do to avoid it
> for standalone tasks is worth the effort.  Otherwise developers are
> forced to learn a complex version control system they might not need.
>
>> The intent is to replace the Developer Hub with procedures based on
>> github.
> For many reasons I still think this is a shortsighted and uninformed
> intent.
>
>> 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.
> That's bad.  I'd prefer one person be responsible for an activity,
> because relying on two is going to slow things down, and things are
> already too slow.
>
>> One major benefit is that the procedure described in reference four
>> is not necessary.
> I don't think that's a major benefit; the procedure has not been used
> for many years.
>
>> 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.
> I'll continue to disagree until you've shown further understanding of
> the process.
>
> If you break the process too much, then I'll bypass it as I've already
> had to do for the existing process breakage; which is why we have
> several point releases of activities in OLPC OS; like Terminal 44.1,
> Wikipedia 38.2, Pippy 70.2, Maze 26.1, GetBooks 16.2, Gears 6.2,
> Fototoon 22.1, FindWords 3.1, and Browse 200.1.  All due to absence of
> maintenance.  Sebastian was quite right to call out the problem yet
> again, and your insistence on process change seems likely to make the
> problem worse.
>