<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi, Walter<br>
<br>
<div class="moz-cite-prefix">On 03/14/2017 11:02 AM, Alex Perez
wrote:<br>
</div>
<blockquote
cite="mid:F89E1D07-068E-4CB9-9BFE-7D67013D818D@alexperez.com"
type="cite"><cite>ASLO is not a source code repository. It’s a
convenience to end users. I know you think they should be one
and the same, and in theory they could be, but I don’t
necessarily see the benefit.</cite><cite><br class="">
</cite>
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" class="">
<div class="">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF" class=""> </div>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</blockquote>
The source code repository for a Sugar activity is the activity
bundle. ASLO is the source for Sugar activity bundles so it is, in
that sense, a source code repository. <br>
<br>
<cite>I don’t see a reason why ASLO couldn’t simply be a front-end,
pointing to .xo activity files which are mirrored elsewhere (even
HTTP-accessible via Git/GitHub, or via a global CDN). That said,
there is some value in hosting the activities directly on ASLO.
There is also some risk, since, if ASLO goes offline, so does
access to all activities.</cite><br>
<br>
I don't think anyone cares where the ASLO link goes. Actually,
mirrors of ASLO would be helpful.<br>
<br>
However, a link to github is not a link to a bundle. It requires
python setup.py dist_xo to create a bundle from github.<br>
<br>
Now we have duplicate systems for developers: developer hub on ASLO
and gaining access to the Sugarlabs github site.<br>
<br>
<div><br class="">
</div>
<cite>Git can absolutely be used locally (with branches, tags, etc)
without external access to the Internet. It was designed to be use
this way. That said, I don’t see why Git needs to be a sugar
activity. It just needs to be a dependency of the
development-specific Sugar packages (RPM/deb/etc)</cite><cite><br>
</cite><br>
I assume by development specific you mean release specific. <br>
<br>
i don't see a problem with git being a 'gnome' application in a
sugar installation. Essentially, the developer needs to make a
commit of the base activity which could be done with the directory
in /home/olpc/Activities (in Ubuntu, the activity may be in
/usr/share/sugar/activities; however, the user can copy to his own
/home/myname/Activities). This would enable reversion to the
previous commit in case a change breaks the activity. <br>
<br>
<cite>If one wanted to update an activity, say TuxMath, now the
first step would be to clone the repository not install the
activity itself. </cite><cite><br class="">
</cite>
<div><cite><br class="">
</cite></div>
<div><cite>This is an incorrect assumption. <br>
<br>
</cite>This illustrates the problem. Yes, one can install the
activity and does not need to refer to the github repository.
However, this assumes that the version in ASLO is the currently
released version. The Browse and TuxMath activities on github are
not available on ASLO, TuxMath is not distributed with 0.110. So a
developer who starts with the ASLO version starts with one that is
broken. I don't believe the ASLO version activity.info links to
the github repository. (It hasn't been updated since 2010). Clone
is probably the wrong word. I suspect the mechanism is to download
the zip file and then run setup.py locally.<cite></cite><cite><br>
<br>
Tony<br>
</cite></div>
<cite> </cite><br>
</body>
</html>