Mark O'Donohue wrote:

> Hi Mike
>
> After some private discussions, I have put in a request to register the
> names,
>
> Firebird Ashes and
> Firebird.
>
> as projects on sourceforge.

This is good news indeed.

> I think that it will take some time to settle on a suitable name (there

are

> too many people in the world - and all the good names are usually already
> taken).

True, but now we at least get a central repository for suggestions about the
new name. Right now it seems to be discussed in a number of places.

> There have been a number of suggestions about how to proceed here. And a
> number of people have suggested things in these groups. Including the

mers

> CVS repository.

I'd say we stick to the SourceForge repository. One of the most distrubing
things to me when trying to get info/keep up-to-date on what's happening is
the multitude of places I have too look (mailing list, two different news
servers and the interbase.com site). Besides, SourceForge contains all we
need, mers don't. I also don't think anyone have started committing to the
mers CVS, and it seems from discussions that it could be a while before
someone does.

> Source Forge I think provides good infrastructure support for opensource
> projects - mainly becuase most of the projects I have followed have

migrated

> there.

It is good. We get all the needed facilities; bugtracking, mailing lists,
web-space, CVS... Not to mention the acessability for people who wants to
participate. We also get web-accessible mailing-list archives.

> I was nominally thinking of "Firebird Ashes" as the initial project for
> gathering together all the released interbase code and probably getting it

to

> a basic compile stage.

This definitely should be priority one. As noted by Ann, the alignment
problems of structs probably have disappeared, why we could use
pre-processed .e->.c files for at least gpre. She also hinted that it would
be possible to get gpre to read a local file instead of the DB when using
it, why we could break the chicken-and-egg syndrome we now suffer. There was
a problem with compiling on Cray, but I don't know what that problem is and
I currently don't have access to one to try to find out.

Now, what kind of resource would we initially need on SourceForge?

I think we need the following:

- A web page to ease access to the current (SourceForge local) tarballs,
links to the .308 IBConsole and some other useful stuff (e.g. the posted
build instructions). If for nothing else, to let people know that the
project exists and is doing something. We could possibly also have som links
to (free) client tools/libraries. We should also repackage the Win32
binaries to contain the .308 IBConsole, and a newer version of msvcrt.dll.

- A mailing list IB-dev (or Firebird-dev). I think its opening statement
should contain "No politics, just code/coding issues.". :-)

- A mailing list "IB-patches".

- Maybe a list "IB-build" that holds building issues, hints and so on.

I think the following thing are the ones we must settle on before we open
the CVS archive (in no particular order):
- Coding standards. I've said it before, and I stand by it: The current code
sucks.
- An overview of the architecture. I think the overview at interbase.com
could serve as a starting point, but I think we need a more thurough
understanding of the different subsystems, dependencies and so on. We
probably should get some graphical representation of the relationships up on
the website in due time also.
- A restructure of the (CVS to be) tree. To make an educaded (and not too
painful) transition to a new tree I think we need to understand the code
first.

> Then after discussion and agreement on what sort of "derived product" and
> "derived licence" is allowable and desired. We can consolidate it under

the

> newer "Firebird" project.

I think that the license we should *aim* for should be LGPL. AFAIK that
would give all freedom and none of the current restrictions.

/Mike