RELEASE on March, 1st !!!

[Konstantin Popov]

[ ]
> 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.
hmm.. objectively speaking, you can obtain this information as easy as
I do. GCC installation is straightforward, while we're loosing time
analyzing each other's code, typing, and due to communication latency.

> 
> >    . 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.
concerning MOGUL I'm only suggesting things: here I believe 
such a clarification would make life easier for MOGUL users.

> 
> >    . 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.
How would you define "add-on"?

> 
> >      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
I don't get the point about "earlier in the process": it could only be
the case if other pre-stdlib components were built with ozmake too.

> 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.
yes, I agree.

[ ]
> > 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".
.. still is :-)

> 
> > 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.
well, there are two question: (a) where is the server and who has
access to it, and (b) what's the technology used. Now I'm DEFINITELY
worried about the first part. Maybe, as I will update it, I'll become
worried about the other part as well - but sorry, not now.

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

after some discussions, it looks like we just feel that the old server
is OK, while certain people specifically say the old one is better.  I
prefer not to fix things until they're broken, you know.

> 
> I am willing to help implement such a solution, but I don't want to do
> it alone.
It sounds like we'll have to wait with that one. Maybe the MOz'04
event will be a good place/time to have a more throughout discussion.

Do I understand it right?

[ ]

Cheers,

 --- Kostja.