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.
