Re: [Sugar-devel] [IAEP] Testing of Activities

[Tony Anderson]

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 > 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
>
> wrote:
>
> On Wed, Apr 19, 2017 at 1:30 AM, Tony Anderson

Re: [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.



___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [IAEP] Testing of Activities

[Tony Anderson]

Hi Walter,

Based on my understanding of the GitHub process, I posted issues 
documenting the problems.


Tony

On 04/20/2017 12:09 AM, 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 
> wrote:


On Wed, Apr 19, 2017 at 1:30 AM, Tony Anderson
> 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=2017-01-01=2017-01-31=%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@lists.sugarlabs.org

http://lists.sugarlabs.org/listinfo/sugar-devel





--
Walter Bender
Sugar Labs
http://www.sugarlabs.org



___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [IAEP] Testing of Activities

[Walter Bender]

On Wed, Apr 19, 2017 at 3:23 PM, 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
>
> ??
>

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 <
> cjlhomeaddr...@gmail.com>
> > wrote:
> >
> > On Wed, Apr 19, 2017 at 1:30 AM, Tony Anderson <
> tony_ander...@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 

Re: [Sugar-devel] [IAEP] Testing of Activities

[D. Joe]

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.

-- 
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 
> wrote:
> 
> On Wed, Apr 19, 2017 at 1:30 AM, Tony Anderson 
> 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 

Re: [Sugar-devel] [IAEP] Testing of Activities

[Walter Bender]

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 
wrote:

> On Wed, Apr 19, 2017 at 1:30 AM, Tony Anderson 
> 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=2017-01-01;
> to=2017-01-31=%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@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>



-- 
Walter Bender
Sugar Labs
http://www.sugarlabs.org

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [IAEP] Testing of Activities

[Chris Leonard]

On Wed, Apr 19, 2017 at 1:30 AM, Tony Anderson  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=2017-01-01=2017-01-31=%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@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel