Comments follow...<br><br><div class="gmail_quote">On Mon, Jul 14, 2008 at 4:09 PM, C. Scott Ananian <<a href="mailto:cscott@laptop.org">cscott@laptop.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="Ih2E3d">On Mon, Jul 14, 2008 at 3:22 PM, Eben Eliason <<a href="mailto:eben.eliason@gmail.com">eben.eliason@gmail.com</a>> wrote:<br>
> They don't get it? Or they don't get how a single integer is supposed to be<br>
> sufficient, and therefor use their own methods? Do you have examples of<br>
> specific "random and bogus" strings we can look at to see what's been tried?<br>
<br>
</div>On an XO:<br>
$ python2.5<br>
>>> act_page = '<a href="http://wiki.laptop.org/go/Activities" target="_blank">http://wiki.laptop.org/go/Activities</a>'<br>
>>> import urlparse, re, urllib<br>
>>> import bitfrost.update.actutils as actutils<br>
>>> urls = [urlparse.urljoin(act_page, url) for url in re.findall(r'href="([^"]*)"', urllib.urlopen(act_page).read()) if url.endswith('.xo')]<br>
>>> for u in urls:<br>
... try:<br>
... cp = actutils.activity_info_from_url(u)<br>
... except:<br>
... print "BAD <a href="http://activity.info" target="_blank">activity.info</a>", u<br>
... continue<br>
... if not cp.has_option('Activity','activity_version'):<br>
... print "MISSING VERSION", u<br>
... continue<br>
... try:<br>
... pass<br>
... except: pass<br>
... v = cp.get('Activity','activity_version')<br>
... try:<br>
... assert not v.startswith('0')<br>
... assert not '.' in v<br>
... v = int(v)<br>
... except:<br>
... print "BAD VERSION", u, v<br>
...<br>
MISSING VERSION <a href="http://wiki.laptop.org/images/1/1d/ViewSlides-3.xo" target="_blank">http://wiki.laptop.org/images/1/1d/ViewSlides-3.xo</a><br>
BAD <a href="http://activity.info" target="_blank">activity.info</a> <a href="http://wiki.laptop.org/images/7/7e/Gmail-2.xo" target="_blank">http://wiki.laptop.org/images/7/7e/Gmail-2.xo</a><br>
BAD <a href="http://activity.info" target="_blank">activity.info</a> <a href="http://opteron.9grid.us/olpc/inferno-012808.xo" target="_blank">http://opteron.9grid.us/olpc/inferno-012808.xo</a><br>
MISSING VERSION <a href="http://wiki.laptop.org/images/b/b2/ProducePuzzle.xo" target="_blank">http://wiki.laptop.org/images/b/b2/ProducePuzzle.xo</a><br>
BAD <a href="http://activity.info" target="_blank">activity.info</a> <a href="http://www.linuxuser.at/dl.php?i=ImageQuiz.xo" target="_blank">http://www.linuxuser.at/dl.php?i=ImageQuiz.xo</a><br>
<br>
This is under-reported, since many of the bad activities just set<br>
activity_version=1:<br>
<br>
>>> def bad_ver(v):<br>
... try:<br>
... assert not v.startswith('0')<br>
... int(v)<br>
... return False # good<br>
... except:<br>
... return True<br>
...<br>
>>> vers = [v for v in re.findall(r'<span class="olpc-activity-version">([^<]*)</span>', urllib.urlopen(act_page).read()) if bad_ver(v)]<br>
>>> vers<br>
['\xe2\x80\x93', '\xe2\x80\x93', '\xe2\x80\x93', '\xe2\x80\x93',<br>
'1-beta', '1.4', '1.7', '\xe2\x80\x93', '0.29', '3.3', '\xe2\x80\x93',<br>
'012808', '\xe2\x80\x93', '\xe2\x80\x93', '0.4', '', '0.33 - beta 3',<br>
'\xe2\x80\x93', '\xe2\x80\x93', '\xe2\x80\x93', '\xe2\x80\x93',<br>
'\xe2\x80\x93', '\xe2\x80\x93', '\xe2\x80\x93', '\xe2\x80\x93',<br>
'\xe2\x80\x93', '\xe2\x80\x93', '\xe2\x80\x93', '\xe2\x80\x93',<br>
'\xe2\x80\x93', '\xe2\x80\x93', '\xe2\x80\x93', '\xe2\x80\x93', '0.2',<br>
'080601', '080601', '080601', '080601', '080601', '080601', '080601',<br>
'080601', '080601', '080601', '', '\xe2\x80\x93', '[beta-1]',<br>
'\xe2\x80\x93', '0.1', '\xe2\x80\x93', '0.1']<br>
<div class="Ih2E3d">>>><br>
<br>
>> b) There is an alternative mechanism already in place for handling<br>
>> dependencies on specific versions, documented in the [[Activity<br>
>> bundles]] entry for 'update_url'. Basically, you can specify a<br>
>> different version number as appropriate based on the current OS build,<br>
>> release version, and release major version. So you can say, "version<br>
>> 8 if you are using 8.1, or version 9 if you are using 8.2".<br>
><br>
> How does this actually help the user, or the tech support team when someone<br>
> wants to know "what version of chat works with 9.1.0?" Short of saying<br>
> "Well, the system will (should) know if it can support an activity, so<br>
> download it and see..." what do we have? We say "Well, versions 36-38, and<br>
> also 40, and also 42, work with 9.1, but not 39 and 41...those are bugfixes<br>
> for 8.2". This seems silly to me. Just say versions 4.x and 5.x work with<br>
> 8.2 and 6.x works with 9.1. This also makes displaying multiple versions<br>
> (activity "threads") possible in the OS. Otherwise how can we reasonable<br>
> sort/group the activities in any way that makes sense?<br>
> - Eben<br>
<br>
</div>Just say, "does the activity updater show an update for your version<br>
of Chat? if so, install it, please."<br></blockquote><div><br></div><div>I'm not sure this satisfies me. It might accurately handle the use case of updating when upgrading, assuming that activity developers are very careful to add extra info about compatibility into the .info file. It doesn't however, make it easy to decide what version of an activity to download if I've never used it before, and I'm not on the most recent release of Sugar. What if I still have 8.1 even though 8.2 is out, and I find a cool new science activity I want. What version to get? Well, maybe 23. Maybe 32. Maybe 24-31 are all incompatible because of a new API in 8.2, but how would I know? Is the best suggestion to download a really old version and then wait for it to inform me of an update?</div>
<div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
The alternative is not going to work, because the activity authors<br>
can't keep their bundle ids straight, much less collectively agree to<br>
use release-synchronized version numbers in a sane way. You are<br>
proposing a more complicated system, which just introduces more ways<br>
to go wrong w/o actually addressing any part of the real metadata<br>
problem.</blockquote><div><br></div><div>So make the requirements more strict. Don't run/install a bundle unless it adheres to the format. We should be doing that anyway. Develop can easily handle a major/minor revision checkbox to keep things in sync with little overhead for those that care and NO overhead for those that don't (let them ignore the possibility of minor releases; it won't break things). The major-version-number-only approach is a valid subset of a major-minor approach.</div>
<div><br></div><div>Moreover, I'm not sure what's going on with many of these version numbers. Those of the form 080601 seem to be using dates. OK, that's wrong. I have no idea what the x90 type of versioning is about, but there are so many it seems there must be a single developer/group using that in a bunch of their own activities, which makes it an endemic and not an epidemic problem. The remainder of them seem to be well formed major.minor numbers (minus a few which append "beta" unnecessarily, since as Brian noted previously using 0 as the major version number can satisfy that).</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
As regard to sorting/grouping: we already discussed that at our last<br>
mini-conference: simple ordering by version number, with group breaks<br>
when signature changes. </blockquote><div><br></div><div>I agree with the signature approach. However, I don't really know what happens when I have 37, 38, and 39 where 39 is a "bugfix" release of 37, and 39 is a "brand new version"...I'd prefer to see them ordered 37, 39, 38, to coincide with the "level of newness". This is something we will lose completely without a minor release number. The logical assumption is that "the bigger the number, the better/newer it is", which is blatantly false when point releases are intermixed with brand new versions with ever-increasing version numbers. I might decide I need to clear up space, and so delete versions 37 and 38, thinking I was keeping the latest and greatest version 39 and be quite disappointed.</div>
<div><br></div><div>- Eben</div></div>