[Sugar-devel] [IAEP] Testing of Activities

[Walter Bender]

On Wed, Apr 19, 2017 at 3:23 PM, D. Joe <sugarlabs at etrumeus.com> 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
>
> ??
>

In the past, we left it up to individual maintainers to do releases.
Typically the git tag matched the release number. I don't see why we would
not continue with that approach to tagging, even if we come up with a
different model for when to release. Perhaps the Sugar release manager has
some thoughts? Ignacio?

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

As per above, I don't think we need to tag with each commit. But at some
point, a maintainer would decide there was sufficient reason to issue a new
release.

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

Using separate branches for development is good practice. Keeping the
master branch === the ALSO version is not something we have been doing in
the past, but it may be a decent approach to maintaining sync.

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

We've tried to stay away from this in the past. Flatpack could help us
here.  In reality, the percentage of activities with arch dependencies is
pretty small.

>
> 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.
>
> --
> Joe
>
> On Wed, Apr 19, 2017 at 12:09:55PM -0400, Walter Bender wrote:
> > In the meantime, it may make sense to walk through all of the repos in
> > sugarlabs on GH and ensure that those with changes get updated version
> numbers,
> > new .xo and .gtar files, and we update ASLO and downloads. It seems our
> only
> > mechanism for doing this is manual at the moment. Tony, if you publish
> the list
> > of activities that are working properly from your recent tests, I will
> begin
> > the process of updating version numbers (and ensuring that the correct
> repo
> > path is in the activity.info bundle) and making the new bundles.
> >
> > -walter
> >
> > On Wed, Apr 19, 2017 at 10:19 AM, Chris Leonard <
> cjlhomeaddress at gmail.com>
> > wrote:
> >
> >     On Wed, Apr 19, 2017 at 1:30 AM, Tony Anderson <
> tony_anderson at usa.net>
> >     wrote:
> >     > I spent the last two plus days testing the 137 activities with
> >     repositories
> >     > in github/sugarlabs.
> >
> >     Thank you for this effort, clearly additional follow up is required
> >     and I hope it occurs.
> >
> >     > Localization also needs some attention. The setup.py enables a
> developer
> >     to
> >     > generate a master Pot file while building a bundle for release to
> ASLO.
> >     That
> >     > is probably the limit of the developer's responsibility. However,
> >     existing
> >     > activities over time have developed localization for many
> languages.
> >     Changes
> >     > to the messages will need new translations. Perhaps the developer
> can use
> >     > diff to find differences in the Pot and to eliminate un-needed
> changes
> >     and
> >     > test that new messages are passed through. This could enable prompt
> >     release
> >     > of a new version without waiting for the localization team to
> provide
> >     > translations for dozens of languages.
> >
> >     For a very long time, instructions to developers have been "run the
> >     POT generation and never ever touch anything in the PO directory
> >     again, The L10n team will take care of the rest of it for you.".
> >     Unfortunately over the course of time, with changes in Pootle
> >     versions, migration of our repositories to GitHub and the decay of a
> >     "pootle-helpers" script set originally created by Sayamindu Dasgupta,
> >     the early tight and hands-free integration between Pootle and the
> >     repos has suffered and much of the process has returned to manual
> >     intervention.  The best path back to such a L10n nirvana is an
> >     upcoming release of Pootle (ver 2.8) that brings back repo
> integration
> >     through the implementation of the pootle-fs file system.
> >
> >     At the present time if the messages of an activity are being changed,
> >     we are still dependent upon periodic refreshes of the POT file which
> >     can be accomplished with "setup.py genpot".  I manually upload that
> >     renewed template to Pootle and refresh the existing PO files from the
> >     template and call for completion of any new strings.  With the
> >     gracious help of James Cameron in generating refreshed POT files,
> this
> >     process has been initiated (and substantially completed) for the
> >     entire Fructose collection and I am systematically committing the
> >     refreshed PO files to the GitHub repos.(feel free to examine/monitor
> >     pull request activity by github user leonardcj).
> >
> >     https://github.com/leonardcj?tab=overview&from=2017-01-01&
> to=2017-01-31&
> >     utf8=%E2%9C%93
> >
> >     As for suggesting the reuse of strings common to already translated
> >     activities, this is clearly a "best i18n practice", that should be
> >     encouraged.
> >
> >     I do envision sheparding us back to an enlightened era where
> >     developers largely can expect localizers to take care of things for
> >     them (primarily through a migration to the 2.8 version of pootle when
> >     finally released (or possibly 2.8.1 bug fix version if one follows
> >     traditional Microsoft upgrade best practices).  Ideally, Pootle would
> >     take care of POT regeneration on the backend, as we used to have it
> >     do.
> >
> >     cjl
> >     _______________________________________________
> >     Sugar-devel mailing list
> >     Sugar-devel at lists.sugarlabs.org
> >     http://lists.sugarlabs.org/listinfo/sugar-devel
> >
> >
> >
> >
> > --
> > Walter Bender
> > Sugar Labs
> > http://www.sugarlabs.org
> >
>
> > _______________________________________________
> > Sugar-devel mailing list
> > Sugar-devel at lists.sugarlabs.org
> > http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
> --
> --
> Joe   On ceding power to tech companies: http://xkcd.com/1118/
> man screen | grep -A2 weird
>   A weird imagination is most useful to gain full advantage of
>   all the features.
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>



-- 
Walter Bender
Sugar Labs
http://www.sugarlabs.org
<http://www.sugarlabs.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20170419/46a64c8a/attachment-0001.html>