[Sugar-devel] [IAEP] Testing of Activities

[Tony Anderson]

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