RELEASE on March, 1st !!!

[duchier at ps.uni-sb.de]

Konstantin Popov <kost at sics.se> writes:

> 0. IS ANYBODY OUT THERE??
>    That is, SERIOUSLY, I'd like to know who cares at all, and whom we
>    (Kevin+myself) can count on. I learned, for instance, that some
>    people recently changed their employer.

I was wondering the same thing.  Since you have been placed in charge
of the release, it is up to you to keep things moving and the
information flowing (a thankless task, unfortunately).  I certainly
have no idea what is or is not going on.  Note that you mentioned a
problem with possibly non-optimal code generation in gcc3 and I looked
into it, but then I needed some benchmark data (comparing gcc2.95 and
gcc3 on a program I provided) which I cannot easily obtain myself and
you never got back to me.

>    . update the MOGUL web page such that it becomes clear that one 
>      need ozmake [for dealing with packages] and where&how to get it.

I can make this clearer, but we need to keep in mind that, while most
packages in MOGUL use ozmake, there are some which do not.

>    . leave the contrib&mozart-stdlib things in place for now unless
>      someone really wants to fix it (the idea is, if I'm not mistaken,
>      that all 'contrib' stuff will eventually go to 'mozart-stdlib'.

some thing like that, yes.  mozart-stdlib should really be the
"standard" library.  while the regex interface probably belongs in it,
micq does not.  Some contributions should instead be offered as
optional add-ons.

>      We'd suggest also the ozmake SOURCES go there as well so that
>      bootstrapping the stdlib begins with building the ozmake, which
>      is then used for everything else).

if this makes things easier for the time being, then let's do it - I
think that, in the future, we may want to have ozmake (or a similar
tool) earlier in the build process - but we can move it again when the
issue arises.  One purely aesthetic issue is that I was hoping that
everything in the mozart-stdlib could be built using ozmake,
unfortunately that's a chicken and egg problem with ozmake itself
(when the pickle format changes) - this is why ozmake also needs a
Makefile for those situations where ozmake itself cannot be used.

>    Kevin also pointed out that currently the MOGUL web interface does
>    not support multiple "platforms" - after the release packages will
>    have to be updated (can that be done automatically?) and everyone
>    will have to use the new [1.3.0] version. I do care for QTK in
>    particular (since it's in the book).

I am glad you raise this issue because that is also very much worrying
me.  It's a really stupid situation because I don't think there are
any packages in MOGUL that distribute pre-compiled functors.  This
means that the current pickles only use the very plain and simple data
part of the pickle format, which I don't think changed when the pickle
format last changed.

by the way, qtk is not a problem since it comes in mozart-stdlib.

Let me summarize the situation:

when creating a package, ozmake builds a big datastructure with (1)
the makefile information as a record and (2) the data, i.e. a list of
pairs (filename,filecontents).  Then this datastructure has to be
saved into a *.pkg file.

   - up to version 0.86, I was using Pickle.saveCompressed as this was
     the only way to save data with compression.  This had the
     unfortunate consequence that *.pkg files where dependent on the
     pickle version.  Most packages currently in MOGUL are in this
     case.

   - starting at version 0.87, I use Open.compressedFile support if
     available, with my own pickler written in Oz.  This has the
     advantage that *.pkg are now independent of the pickle version,
     but my pickler (and unpickler) is less performant than the real
     thing.

     ozmake >=0.87 is written in such a way that it can use
     transparently old-style and new-style *.pkg files, but of course
     this does not help with old *.pkg files that use an incompatible
     pickle version.

     In principle, this problem can be overcome by going through text
     pickles, but that approach requires both a 1.2.5 and a 1.3.0
     installation.

I think that the best we can do is to clearly label packages as
old-style and new-style.  I can extend ozmake --publish to
automatically include such information, and then extend MOGUL to
display it.  I'll have to think about this some more.  Suggestions
welcome!

> 3. packaging
>    Probably the bulkiest chunk of work. I'm afraid we might miss
>    information about Windows (apparently, the Windows packaging
>    business is going to change hands now). MacOS X & other platforms
>    (aka FreeBSD) seem to be a bit ad'hoc as well. WE WOULD WELCOME ANY
>    INPUT - HELP, INFORMATION, DOCUMENTATION HERE!!! Credits will be 
>    of course given..

Perhaps it is time to work again on the installation and packaging
documentation.  There was my "Secret Sucky Guide To Making Releases".

> 4. web page & access
>    As usual, we either need the access to the web page OR someone who
>    will fix the webpage himself. PLEASE RESPOND ASAP!! I have to know
>    what to do next - start looking at the web server, discuss things
>    with involved person(s) or even searching for the responsible
>    partner!

I can update webpages at SB, but this situation will continue to be a
problem.  As an alternative, I have talked to various people about
replacing the current web site with one that is plone based.  Plone
(www.plone.org) is a content management system.  A considerable
advantage of it is that it can be fully edited through its web
management interface.  This means that a number of people at various
institutions can be granted manager priviledges for the plone site
without having any particular other access rights to the hosting
machine.

This would be a perfect time to revise and update our public face.  I
did a quick and dirty proof of concept at tdg.loria.fr/mozart just to
get a feel for things.

I am willing to help implement such a solution, but I don't want to do
it alone.

> 5. bugs

I'll have a look at your list this evening.  Thanks for compiling it.

Cheers,

-- 
Denys Duchier - Équipe Calligramme - LORIA, Nancy, France