Hi again,
Yep, good to be back :) I won't have so much free time to spent on
flood development, but I might do something useful anyway. I've already
talked to Justin about few flood related issues and he insisted on making them
public, so here's it is...
We need a 'real' release. That is, one that follows httpd release guidelines
as close as possible. This produces a few problems, in particular:
1. KEYS file
In order to sign release tarballs, RM needs a valid PGP/GPG key in public KEYS
file. I suggested separate KEYS file, but since Justin pointed out that
there's no problem importing given key to httpd KEYS file (even if that
person is not directly related to httpd development) -- it might not be the
best idea after all.
2. tarball signing
We have to sing releases. As Sander said -- even if flood uses no special
privileges and won't open socket listening for incoming connection, we have to
sign tarballs, to assure everybody, that even httpd subproject releases are
secure and high quality. I'm +1 on this.
3. release roll script
httpd and apr have their roll scripts which make RM work easier. I think we
need such a script for flood. Even if this would mean just few simple lines of
sh code, it's sure nice to help RM do it's job. Unless somebody will pick it
up first, I'm going to look at httpd/apr scripts and prepare starter for
flood.
It's about time to get my and Phi-Long's patches out the door, so after we
have things sorted out -- let's do a 1.1 release. After that we have to define
showstoppers for 1.2 and start to work on that. My key task for 1.2 is
documentation. Merge with httpd-docs subprojects right now seems tricky to me,
but we can have our own xsl for the time beeing. And that is just what I'm
gonna work on right now.
regards,
Jacek Prucia
