I believe the plan is that GitHub is the source repository for the
activities and git is used to
maintain version control. Activities are published to ASLO with the
bundles built by setup.py.
As in most uses of git, a new bundle requires the version number to be
incremented with the corresponding git tag.
In this way, earler versions could be recreated as needed to reproduce
reported problems.
How to handle activities across the different supported environments
needs discussion. For the XO, the primary issue was storage
space. The current technique is to provide binaries for the supported
platforms with a software test in the activity to determine where it
is being run. This is elegant but expands the size of the bundle. In one
case, I saw that the 32 bit binaries took 15MB and the 64 bit binaries took
30MB. On the other hand, it is likely that newer platforms will not be
storage limited.
There are two forms of activities: Python and Web. In general these will
run on all systems. The problem is the use of binary modules (often
compiled C code).
The more serious problem is the changing content of Sugar itself. Many
activities currently fail because Sugar no longer includes modules such
as hulahop or abiword. The developers would like all activities to be
ported from GTK2 to GTK3 to reduce the duplicate code included in Sugar.
However, there are currently over 300 activities in ASLO that would need
to be converted.
Tony
On 04/20/2017 03:23 AM, D. Joe wrote:
So, is the idea here to add new git tags, for example:
https://github.com/sugarlabs/write-activity/releases
to keep the tags in line with the value of activity_version as changed, for
instance, in
this commit:
https://github.com/sugarlabs/write-activity/commit/b95f2901941c0cff871124e042c76e4340517ebb
for the file activity.info
https://github.com/sugarlabs/write-activity/blob/master/activity/activity.info
??
Just trying to get a handle here on how this is to be tracked and
maintained, how.
Do we increment activity versions with each commit? I see some activities
hosted on github have something of a branch structure, but its not clear to
me if or how one would use this to differentiate between things that match
the ASLO versions versus those that have diverged from what's on ASLO.
I have no great background in release engineering, but it would make sense
to me to have, eg, 'master' contain only sets of commits that correspond
with things that have been put on ASLO, and a "development" branch (or
whatever name) which gets tagged with the next, upcoming version number and
continues to diverge from ASLO until such time as it gets merged back into
"master", ASLO gets updated, and the version number in "development"
incremented.
Or maybe there should branches, one for each platform? This is the point at
which a "sugarizer" branch might be able to accomodate activities targeted
at that platform, but still share, eg, design elements with the desktop
activity, perhaps? Would, then, an "ASLO" branch track only what runs on
XOs? Or should each model get its own branch so we know what runs on what?
Would each GNU/Linux distro get its own branch, eg "fedora-27"?
On the one hand, I'm very leery of the latter approach because there's
already such a proliferation of ... stuff in the broader Sugar community.
On the other hand, this is just an attempt to figure out how to make some
sense of what is already out there using some of the tools at hand meant
specifically for managing development complexity.
_______________________________________________
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
