<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
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
<br>
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.<br>
<br>
As we move beyond the XO, our problem with storage capacity should
be reduced so that the binary dependencies could be handled <br>
by a platform test. Currently, there are three: Arm, 32 bit, and 64
bit. <br>
<br>
Tony<br>
<br>
<div class="moz-cite-prefix">On 04/20/2017 03:51 AM, Walter Bender
wrote:<br>
</div>
<blockquote
cite="mid:CADf7C8t8TvpoJdYL6uSyL3ywtABWwHcp-PZReJ1k_B5CmL+kfQ@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, Apr 19, 2017 at 3:23 PM, D.
Joe <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:sugarlabs@etrumeus.com" target="_blank">sugarlabs@etrumeus.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
So, is the idea here to add new git tags, for example:<br>
<br>
<a moz-do-not-send="true"
href="https://github.com/sugarlabs/write-activity/releases"
rel="noreferrer" target="_blank">https://github.com/sugarlabs/<wbr>write-activity/releases</a><br>
<br>
to keep the tags in line with the value of
activity_version as changed, for instance, in<br>
this commit:<br>
<br>
<a moz-do-not-send="true"
href="https://github.com/sugarlabs/write-activity/commit/b95f2901941c0cff871124e042c76e4340517ebb"
rel="noreferrer" target="_blank">https://github.com/sugarlabs/<wbr>write-activity/commit/<wbr>b95f2901941c0cff871124e042c76e<wbr>4340517ebb</a><br>
<br>
for the file <a moz-do-not-send="true"
href="http://activity.info" rel="noreferrer"
target="_blank">activity.info</a><br>
<br>
<a moz-do-not-send="true"
href="https://github.com/sugarlabs/write-activity/blob/master/activity/activity.info"
rel="noreferrer" target="_blank">https://github.com/sugarlabs/<wbr>write-activity/blob/master/<wbr>activity/activity.info</a><br>
<br>
??<br>
</blockquote>
<div><br>
</div>
<div>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? </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Just trying to get a handle here on how this is to be
tracked and<br>
maintained, how.<br>
<br>
Do we increment activity versions with each commit? I see
some activities<br>
hosted on github have something of a branch structure, but
its not clear to<br>
me if or how one would use this to differentiate between
things that match<br>
the ASLO versions versus those that have diverged from
what's on ASLO.<br>
</blockquote>
<div><br>
</div>
<div>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. </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I have no great background in release engineering, but it
would make sense<br>
to me to have, eg, 'master' contain only sets of commits
that correspond<br>
with things that have been put on ASLO, and a
"development" branch (or<br>
whatever name) which gets tagged with the next, upcoming
version number and<br>
continues to diverge from ASLO until such time as it gets
merged back into<br>
"master", ASLO gets updated, and the version number in
"development"<br>
incremented.<br>
</blockquote>
<div><br>
</div>
<div>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.</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Or maybe there should branches, one for each platform?
This is the point at<br>
which a "sugarizer" branch might be able to accomodate
activities targeted<br>
at that platform, but still share, eg, design elements
with the desktop<br>
activity, perhaps? Would, then, an "ASLO" branch track
only what runs on<br>
XOs? Or should each model get its own branch so we know
what runs on what?<br>
Would each GNU/Linux distro get its own branch, eg
"fedora-27"?<br>
</blockquote>
<div><br>
</div>
<div>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.</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On the one hand, I'm very leery of the latter approach
because there's<br>
already such a proliferation of ... stuff in the broader
Sugar community.<br>
On the other hand, this is just an attempt to figure out
how to make some<br>
sense of what is already out there using some of the tools
at hand meant<br>
specifically for managing development complexity.<br>
<br>
--<br>
Joe<br>
<div class="HOEnZb">
<div class="h5"><br>
On Wed, Apr 19, 2017 at 12:09:55PM -0400, Walter
Bender wrote:<br>
> In the meantime, it may make sense to walk
through all of the repos in<br>
> sugarlabs on GH and ensure that those with
changes get updated version numbers,<br>
> new .xo and .gtar files, and we update ASLO and
downloads. It seems our only<br>
> mechanism for doing this is manual at the moment.
Tony, if you publish the list<br>
> of activities that are working properly from your
recent tests, I will begin<br>
> the process of updating version numbers (and
ensuring that the correct repo<br>
> path is in the <a moz-do-not-send="true"
href="http://activity.info" rel="noreferrer"
target="_blank">activity.info</a> bundle) and making
the new bundles.<br>
><br>
> -walter<br>
><br>
> On Wed, Apr 19, 2017 at 10:19 AM, Chris Leonard
<<a moz-do-not-send="true"
href="mailto:cjlhomeaddress@gmail.com">cjlhomeaddress@gmail.com</a>><br>
> wrote:<br>
><br>
> On Wed, Apr 19, 2017 at 1:30 AM, Tony
Anderson <<a moz-do-not-send="true"
href="mailto:tony_anderson@usa.net">tony_anderson@usa.net</a>><br>
> wrote:<br>
> > I spent the last two plus days testing
the 137 activities with<br>
> repositories<br>
> > in github/sugarlabs.<br>
><br>
> Thank you for this effort, clearly additional
follow up is required<br>
> and I hope it occurs.<br>
><br>
> > Localization also needs some attention.
The setup.py enables a developer<br>
> to<br>
> > generate a master Pot file while
building a bundle for release to ASLO.<br>
> That<br>
> > is probably the limit of the developer's
responsibility. However,<br>
> existing<br>
> > activities over time have developed
localization for many languages.<br>
> Changes<br>
> > to the messages will need new
translations. Perhaps the developer can use<br>
> > diff to find differences in the Pot and
to eliminate un-needed changes<br>
> and<br>
> > test that new messages are passed
through. This could enable prompt<br>
> release<br>
> > of a new version without waiting for the
localization team to provide<br>
> > translations for dozens of languages.<br>
><br>
> For a very long time, instructions to
developers have been "run the<br>
> POT generation and never ever touch anything
in the PO directory<br>
> again, The L10n team will take care of the
rest of it for you.".<br>
> Unfortunately over the course of time, with
changes in Pootle<br>
> versions, migration of our repositories to
GitHub and the decay of a<br>
> "pootle-helpers" script set originally
created by Sayamindu Dasgupta,<br>
> the early tight and hands-free integration
between Pootle and the<br>
> repos has suffered and much of the process
has returned to manual<br>
> intervention. The best path back to such a
L10n nirvana is an<br>
> upcoming release of Pootle (ver 2.8) that
brings back repo integration<br>
> through the implementation of the pootle-fs
file system.<br>
><br>
> At the present time if the messages of an
activity are being changed,<br>
> we are still dependent upon periodic
refreshes of the POT file which<br>
> can be accomplished with "setup.py genpot".
I manually upload that<br>
> renewed template to Pootle and refresh the
existing PO files from the<br>
> template and call for completion of any new
strings. With the<br>
> gracious help of James Cameron in generating
refreshed POT files, this<br>
> process has been initiated (and substantially
completed) for the<br>
> entire Fructose collection and I am
systematically committing the<br>
> refreshed PO files to the GitHub repos.(feel
free to examine/monitor<br>
> pull request activity by github user
leonardcj).<br>
><br>
> <a moz-do-not-send="true"
href="https://github.com/leonardcj?tab=overview&from=2017-01-01&to=2017-01-31&"
rel="noreferrer" target="_blank">https://github.com/leonardcj?<wbr>tab=overview&from=2017-01-01&<wbr>to=2017-01-31&</a><br>
> utf8=%E2%9C%93<br>
><br>
> As for suggesting the reuse of strings common
to already translated<br>
> activities, this is clearly a "best i18n
practice", that should be<br>
> encouraged.<br>
><br>
> I do envision sheparding us back to an
enlightened era where<br>
> developers largely can expect localizers to
take care of things for<br>
> them (primarily through a migration to the
2.8 version of pootle when<br>
> finally released (or possibly 2.8.1 bug fix
version if one follows<br>
> traditional Microsoft upgrade best
practices). Ideally, Pootle would<br>
> take care of POT regeneration on the backend,
as we used to have it<br>
> do.<br>
><br>
> cjl<br>
> ______________________________<wbr>_________________<br>
> Sugar-devel mailing list<br>
> <a moz-do-not-send="true"
href="mailto:Sugar-devel@lists.sugarlabs.org">Sugar-devel@lists.sugarlabs.<wbr>org</a><br>
> <a moz-do-not-send="true"
href="http://lists.sugarlabs.org/listinfo/sugar-devel"
rel="noreferrer" target="_blank">http://lists.sugarlabs.org/<wbr>listinfo/sugar-devel</a><br>
><br>
><br>
><br>
><br>
> --<br>
> Walter Bender<br>
> Sugar Labs<br>
> <a moz-do-not-send="true"
href="http://www.sugarlabs.org" rel="noreferrer"
target="_blank">http://www.sugarlabs.org</a><br>
><br>
<br>
> ______________________________<wbr>_________________<br>
> Sugar-devel mailing list<br>
> <a moz-do-not-send="true"
href="mailto:Sugar-devel@lists.sugarlabs.org">Sugar-devel@lists.sugarlabs.<wbr>org</a><br>
> <a moz-do-not-send="true"
href="http://lists.sugarlabs.org/listinfo/sugar-devel"
rel="noreferrer" target="_blank">http://lists.sugarlabs.org/<wbr>listinfo/sugar-devel</a><br>
<br>
<br>
--<br>
</div>
</div>
<span class="HOEnZb"><font color="#888888">--<br>
Joe On ceding power to tech companies: <a
moz-do-not-send="true" href="http://xkcd.com/1118/"
rel="noreferrer" target="_blank"><a class="moz-txt-link-freetext" href="http://xkcd.com/1118/">http://xkcd.com/1118/</a></a><br>
man screen | grep -A2 weird<br>
A weird imagination is most useful to gain full
advantage of<br>
all the features.<br>
</font></span>
<div class="HOEnZb">
<div class="h5">______________________________<wbr>_________________<br>
Sugar-devel mailing list<br>
<a moz-do-not-send="true"
href="mailto:Sugar-devel@lists.sugarlabs.org">Sugar-devel@lists.sugarlabs.<wbr>org</a><br>
<a moz-do-not-send="true"
href="http://lists.sugarlabs.org/listinfo/sugar-devel"
rel="noreferrer" target="_blank">http://lists.sugarlabs.org/<wbr>listinfo/sugar-devel</a><br>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<div class="gmail_signature" data-smartmail="gmail_signature">
<div dir="ltr">
<div><font><font>Walter Bender</font></font><br>
<font><font>Sugar Labs</font></font></div>
<div><font><a moz-do-not-send="true"
href="http://www.sugarlabs.org" target="_blank"><font>http://www.sugarlabs.org</font></a></font><br>
<br>
</div>
</div>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Sugar-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Sugar-devel@lists.sugarlabs.org">Sugar-devel@lists.sugarlabs.org</a>
<a class="moz-txt-link-freetext" href="http://lists.sugarlabs.org/listinfo/sugar-devel">http://lists.sugarlabs.org/listinfo/sugar-devel</a>
</pre>
</blockquote>
<br>
</body>
</html>