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