[Squeakfoundation][Fwd: Re: installing squeak on Debian Woody]

[Ian Piumarta]

Hi Andreas,

> What we were trying to achieve with the download page was more along the
> lines of having a single page with ALL relevant information and direct links
> to the stuff you need to run Squeak as well as being easily editable. Check
> out our example at
> 
> http://minnow.cc.gatech.edu/squeak/3262

That's a _lot_ better.  A total pain to update whenever new versions
arrive (and too wide to format into a reasonably-dimensioned browser ;),
but _much_ better all the same.

Now, I have no substantive issues with any reasonable download
organisation (with one very big exception -- which you'll be able to
figure out, later in this message).  So what follows is kind of taking my
position to an extreme, but I'm going to indulge in it anyway as a kind of
thought experiment...

Rather than having nrows*ncols of VM dowloads for Unix on that page (with
so many version numbers screwed into everything that I certainly wouldn't
want to spend an hour editing it and testing every link each time a new
release comes out), explain why having that huge Unix download matrix is
better than having a single link to

  www-sor.inria.fr/~piumarta/squeak

where the entire matrix is reproduced (almost) verbatim (except that you
missed a few archives -- there should be 32 of them in total ;) _and_ is
generated automatically (it takes me less time to rebuild the entire
download matrix than it does to open the editor to change the one variable
defining the version number ;) _and_ in which every one of those download
links is verified automatically each time I rebuild the page?

I don't know if anyone has noticed this but the process is entirely
automated -- from build to publishing the new downloads (and almost all of
the re-sync with SF too ;).  If I change something for Unix and bump the
version number, I run one script and 5 minutes later all affected archives
amongst those 32 have been rebuilt -- and the links to them on the
download page updated and verified for correctness.

> which should give you an idea about what we're after (note that the "info"
> link on Unix VMs goes straight into your primary web site for support)

I still can't see the advantage of reproducing the download links in some
place that's only indirectly connected to their content's origin:  (1) the
matrix is incomplete;  (2) it's unmaintainable (without inordinate amounts
of work each time it changes -- and that's sometimes every few hours for
Unix during beta test);  and (3) I often pay little or no attention to
problem reports that arise from VMs packaged by other people -- and I
suspect you'd feel similarly about repackaged win32 VMs that had been
randomly scrambled.  (I recall Stef, I think, although I could be wrong,
getting quite upset [in public -- which I was not happy about] over
problems with Solaris that arose from somebody repackaging stuff.)

> The whole point of this download page is to make clear what the "standard
> home" for Squeak downloads is, be able to update it easily and provide
> up-to-date information on the individual ports.

As far as Unix goes, the most up-to-date you could possibly get would be
to remove the entire Unix matrix and replace it with one link to the
original Unix download page.  Or even better, one link and a list of the
platforms for which archives are available via that link.  (I would be
more than willing to keep that list up to date -- my OS versions change
far less frequently than do my VM versions. ;)

Apart from anything else, when I'm not distracted with other things, new
betas come out every few days -- sometimes every few hours [*] -- and
nightly automatic builds of the live source tree are available for
download too.

The "download" section for new Unix Squeak users on my page is also much
more detailed, and includes a lot of information that is specific to Unix.  
That section is not going to go away, and reproducing a small "generic"
subset of it elsewhere (along with a bunch of archives that merely incites
people to dive in potentially underprepared) is simply bad for new Unix
users.

Thought experiment terminated. ;)

Cheers,
Ian

[*] Just a silly example: I released beta9 two hours ago.  I'm about to
release beta10 within the next hour -- to incorporate your new
sqOpenGLRenderer fixes (unless I fall asleep first ;).  If it wasn't for
the total automation of the process, which makes creating a new release
(and updating its download links and verifying them) trivial to manage,
beta10 would not be happening any time soon.  It seems strange to want to
deprive anyone of that kind of "liveness" by keeping a second-hand set of
links to stale archives...