Release plan (was: Progress Update)

[Christian Reiniger <warewolf@mayn.de>]

Pierre Phaneuf wrote:

>I agree, what work has been done I am confident is good work and I do
>not suggest ripping them out. I am only suggesting for further works to
>accelerate development.

Ok. Good.

>Use the bazaar. For this, you have to release *working* code. That's the
>only requirement by the way. It might get redesigned and rewritten no
>less than a few times during the course of its life, but that is no
>problem, isn't it? :-)

No, that's how it should be.

>See
>http://tuxedo.org/~esr/writings/cathedral-bazaar/cathedral-bazaar-9.html
>for some thoughts on this (you probably already read this, but a refresh
>doesn't hurt sometimes!)...

I read it several times ;)

http://www.oreilly.com/catalog/opensources/book/
also includes some excellent essays on that topic (the entire book is
available online, but everyone interested in the subject should buy it
nevertheless).

>IMHO, it is worth it investing a *bit* more time on the interface, then
>crap out on the implementation to get a working one, possibly littering
>in comments about ideas you'd have done if you didn't crap out. Then, as
>time permit, you or another contributor (helped by the ideas in your
>comments) go back over the code and fix it.

Welll, yesssssssss. sss.
You *are* right with that - in theory. But in practice it doesn't always
work that way.

With PenguinFile we planned to have a STDIO-clone as API almost from the
start. Such an API makes the thing *extremely* "fixable", yet it is (for
the user) very simple to use and the learning effort is almost zero because
everyone already knows stdio. So that API choice was obviously good.

But as a STDIO clone API is so powerful, there are quite a few things that
it has to support from the start. For example normal paths, including
directory hierarchies. I started implementing that in a very simple way,
but soon I encountered something basic which simply couldn't be done with
that implementation, or only with massive workaround code. So the internal
code for directory/file organization was redesigned and rewritten, making
it more elegant and powerful and able to even cope with many unforseen
situations.

After that I was working to implement all that PakFile access stuff - and
encountered another serious limitation in the internals. So I redesigned
and rewrote them into a generic VFS mechanism. We use only little of the
power of that mechanism now, but it made the code clearer, easier to
understand, reduced dependencies and makes adding more "file system types"
very simple.

Good. When that was done I was happy and started working on the PakFile
writing code which had been neglected for quite some time. And during this
I saw that 
(1) the path/filename processing code that started as something very simple
wasn't so simple anymore. In fact it was now quite a mess, with ugly code
in places where it didn't belong, and with memory leaks that were caused by
it and were almost impossible to fix. So I redesigned and rewrote it.
(2) the binary search tree stuff we used for file lookups before (partly
because I wanted to try that algo I learnt about in UNI) was messy and hard
to debug. So we dumped it and are now replacing it with a simpler (and
faster) hash-based thing.

Now we're almost done with that and it seems as if the system is mature and
"fixable" enough to be released.
See below for more on that.

>> Want to help? ;)
>
>Yes, maybe I could! I don't know yet if the licensing will please my
>Ludus colleagues (we'd prefer something like the MPL rather than the
>LGPL, but this is still better than the GPL).

Er, we're not using the LGPL but rather the X license (and I bet that your
colleagues will prefer that even over the MPL ;)

>be done. We have to work on our next generation stuff (Quadra was more
>of a test of development methods than anything else, but it has already
>proven its addictiveness in its previous DOS-only incarnations).

*grin*

>But maybe PFile could be used as the resource file engine in our next
>generation library toolkit. And we also need a better sound engine.

We'll see what we can do.

>This is too bad, I work nearly 8 hours a day on Ludus Design, and that
>could easily be taken under Ludus Design stuff. We'll see, it will
>depends on what you have and if it proves usable or fixable for our
>tasks.

Making it usable for *any* task was most of the work behind PFile ;)

>> Just as space exploration benefits us (even if it just means discovering
>> some planets rich on prescious elements), optimizing PenguinPlay and
>> spending time on improving its design benefits its users.
>
>Yes. Can I have it now? Can I? Now? 8-)

No. But is tommorow ok? 8-)

No joke - I will upload a new source package to ftp once Bjarke sends me
his namespacified code (that's in some hours I guess). That code won't
compile and it will be buggy, but you can get a pretty detailed impression
from it.

After that we will finish the serialization code and add the missing Win32
support to the URL handling code and then go into code freeze and start
debugging, testing, improving the docs etc. And unless we discover some
serious architectural problem during that time (which is very unlikely) we
will have a useable (and even useful) PFile some weeks later.

For now I'll also link the PFile docs from the homepage. They're slightly
outdated, but not in the significant areas (the PakFile format descriptions
are completely invalid, and some other things, especially towards the end
of the doc, are a bit old).

As for PenguinSound, well, what's the status, Peter? Can we go into code or
at least feature freeze for a 0.1 preview release within, say, one or two
weeks?


BTW, Pierre: This release plan was *not* significantly influenced by your
pressings (just to prevent some misunderstandings ;)


	Christian
-- 

Drive A: not responding...Formatting C: instead