Jeff Dodds wrote:

>
> "reed mideke" <rfm@...> wrote in message
> news:3AF0423B.86C7F8D7@......
> > I mostly lurk here (what little posting I do is usually
> > in the firebird-devel mailing list), but I thought I'd respond to
> > the topic in general. Of all the things the firebird project
> > desperately needs, I'd put a new web site near (or below) the bottom of
> > the list.
>
> What should people do who can't do the things at the top of the list?
>

send five dollars to the name at the top of the list... add
you name to the bottom of the list...
Errr...

What do you want to do... As I see it, after (or maybe even
before coding), the following are high priorities:
1) testing
If you have applications which make significant use
of firebird/interbase, try to run the latest firebird
build (or build your own). If you cannot risk using
firebird with 'live' data, perhaps you have tests
for your own application(s) that you could run it with.
When you find bugs, reduce the bug to the simplest case
you can, and make a detailed bug report.
(writing a "how to report bugs" document would be good too)

If you can't stress the product, test the installation:
For each platform (multiple distributions, in the case
of linux)
* install on a clean machine
* install on a machine with an old version of 'interbase'
* install on a machine with the current borland 'interbase'
* verify that in each case a consistent and functioning
install results.
* what if the drive is full
* what if the user doesn't have the right privileges
* test unintstalls (and find yourself a whole new world
of pain)...
(can you see I've done way too much of this stuff)

or test compatibility:
* what happens if you use a borland client with a firebird
server.
* a firebird client with a borland server
* a 5.x client with a firebird server
* a firebird client with a 5.x server.
* What happens if you link an application with the
borland gds32.dll/gdslib.so and then replace the library
with the firebird one

2) bug report gathering/filtering
Anyone can enter bugs in the sourceforge bug tracker. This
leads to stuff that is not bugs (i.e, user mistakes, misunderstandings
etc.) as well as unreproducable reports, and reports that lack
sufficient information. Sorting through these, eliminating
the ones that are bogus, and making concise reports for the
ones that are real will greatly increase the chance of
them getting fixed. Bugs also get reported on various forums,
and ensuring that these are verified and get into the bug tracker
is important. This might involve followng up with the original
submitter, and/or consulting with the developers.
(to actually change the bugs in sourceforge, you would
have to be signed up as a firebird developer)
If anyone is interested in taking this sort of thing on,
post to firebird-devel first. You would need good knowledge
of firebird+sql+programming to do this.

3) documentation
Figure out what is missing/wrong/oboslete, and write/fix it,
or at least make a list of it and submit it to the mailing lists.

(there are legal problems with doing anything with the released
borland documentation, but release notes, readme's, howtos etc.)
Just collecting things that need to go in the release notes+readme
for the first release would be useful.

Documentation could also include going over our website and
figuring out what is missing/unclear.

4) Installation/packaging/cosmetics
There is a lot of little / semi code stuff that needs
to be done before release. (one that comes to mind is
text that refers to interbase. In some situations this
may have legal implications, so we need to evaluate
instances of this before we call anything a release.)

If none of the above match your desires or skill set, you could
post to this list (and maybe firebird-devel as well) that you are
putting together a list of things to do. Then you will have
something to do (put together the list, which we could certainly
use) and probably find a bunch of other things that need doing.

Or you could hold a bake sale and use the proceeds to buy
a Claudio Valderrama a 40 gig hard drive. Then he would
be really dangerous ;-)

You could also take this message, polish it (or re write it),
and turn it into a 'how can I help' document ;-)
[...]

--
Reed Mideke
email: rfm(at)cruzers.com -If that fails: rfm(at)portalofevil.com