[Sugar-devel] [IAEP] Testing of Activities
Tony Anderson
tony_anderson at usa.net
Wed Apr 19 19:53:56 EDT 2017
I really am a newbie to git, but as I understand it, the master branch
should be the point of development. Publishing an activity to
ASLO should be a branch tagged with the incremented version number. So,
in general, the master branch != the branch of the latest release
published to ASLO.
As we move beyond the XO, our problem with storage capacity should be
reduced so that the binary dependencies could be handled
by a platform test. Currently, there are three: Arm, 32 bit, and 64 bit.
Tony
On 04/20/2017 03:51 AM, Walter Bender wrote:
>
>
> On Wed, Apr 19, 2017 at 3:23 PM, D. Joe <sugarlabs at etrumeus.com
> <mailto:sugarlabs at etrumeus.com>> wrote:
>
>
> So, is the idea here to add new git tags, for example:
>
> https://github.com/sugarlabs/write-activity/releases
> <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
> <https://github.com/sugarlabs/write-activity/commit/b95f2901941c0cff871124e042c76e4340517ebb>
>
> for the file activity.info <http://activity.info>
>
> https://github.com/sugarlabs/write-activity/blob/master/activity/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 <http://activity.info> bundle) and
> making the new bundles.
> >
> > -walter
> >
> > On Wed, Apr 19, 2017 at 10:19 AM, Chris Leonard
> <cjlhomeaddress at gmail.com <mailto:cjlhomeaddress at gmail.com>>
> > wrote:
> >
> > On Wed, Apr 19, 2017 at 1:30 AM, Tony Anderson
> <tony_anderson at usa.net <mailto: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&
> <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
> <mailto:Sugar-devel at lists.sugarlabs.org>
> > http://lists.sugarlabs.org/listinfo/sugar-devel
> <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
> <mailto:Sugar-devel at lists.sugarlabs.org>
> > http://lists.sugarlabs.org/listinfo/sugar-devel
> <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
> <mailto:Sugar-devel at lists.sugarlabs.org>
> http://lists.sugarlabs.org/listinfo/sugar-devel
> <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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20170420/c5370840/attachment-0001.html>
More information about the Sugar-devel
mailing list