Just a quick note to add to this thread. Over the past 24 hours I attempted to build the full CVS on SunOs 5.9, FreeBSD 5.2.1, FreeBSD 4.10 and Red Hat Linux 9. Ordinarily each of the four systems run RC7 except the SunOS which runs 1.2.9. I used the same building tools as for the existing stable versions. All of the above are swappables on the same dev machine which is an SMP and with the exception of Solaris, are unaltered standard installations of dbmail with either MySQL or PgSQL.
In every case the build went fine but the finished binaries failed to connect to the MySQL database which I had rebuilt using the new table names. I had checked the CVS latest SQL and didn't see a database change from 'tablename' to 'dbmail_tablename' so I rebuilt it manually. Maybe I missed something. I altered my PERL GUI DBMA (http://library.mobrien.com/dbmailadministrator/ to match the new table names and it was working fine, adding and deleting users, aliases etc., but dbmail was failing all over the place. I then hacked dbsearch.c, dbmsgbuf.c, authsql.c and db.c and in all changed the table names to their originals then switched dbmail.conf over to a CR7 MySQL database with the original tablenames. After rebuilding dbmail with the altered files it connected correctly to the database. Perhaps there are some inconsistencies in the use of the table names. There are still a few problems with the function of the current CVS. 1) Has anyone got the latest full CVS actually working correctly using the new table names? 2) The current CVS might be a little premature for a candidate release. best... Mike -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Aaron Stone Sent: July 30, 2004 3:39 AM To: DBMAIL Developers Mailinglist Subject: Re: [Dbmail-dev] Re: Arranging the 2.0rc8 source package Michael Häusler <[EMAIL PROTECTED]> said: > So it is lurker-time! Well let me chime in. Thanks to all of you guys for bringing up fresh opinions and points of view. > Sumbry, Simon, I have to disagree with both of you. > In one line: Release early, release often. This is a good motto, but must be tempered with a certain discipline; releases need to remain stable, and upgrades need to make sense. Just throwing code out there is a bad idea, it needs to pass at least a modicum of QA. On the discipline issue, I'm definitely twisting the rules by suggesting that, although we are nominally in a release candidate stage, we're not ready for a release and we need to make a number of fairly significant external changes. A few weeks ago I started acting like a new user, opening up a fresh DBMail and seeing if I could make sense of it, and failed. That's what prompted me to push for changes in our user interfaces (on the command line and in the database). > >> Especially something like table_prefixes (At least dbmail_*). In a > >> day and age where everyone is moving everything into the database, > >> not prefixing the tables would instantly put dbmail at a huge > >> disadvantage > > This whole discussion about prefixes seems awfully trivial to me. > This is just a matter of personal preference. I personally rely on > schemas for separating namespaces (i.e. dbmail.* (Postgres supports this > now)). Introducing prefixes would break my installation. But I would > not complain, if they would be introduced in 2.0, and I would not > complain if they would be introduced in 2.1. This is simply a thing, > which you can't get right for everyone. > This has to be decided somehow. But imho, it should not be a showstopper > for a release, simply because we don't want to come to a decision. I'm not familiar with namespace schemas, is this something that we should be mentioning in our documentation or otherwise making use of? (note that it would have to be query-compatible with MySQL and others) I do realize that it's almost as much personal preference as it is prudent database management (at least in the open source world, where we often have the tables of many projects together in a single database), but I believe that the balance of issues weighs towards adding prefixes sooner rather than later. > > I've been a longtime lurker as well, and am running 1.2.6 in > > production awaiting a stable 2.0 release. I would far prefer to see > > all the invasive changes introduced with the 2.0 release rather than > > having to migrate again to 2.1 or 3.0. > Is this only about prefixes? I don't see any other thing, which would > destabilize the 2.x branch. I believe that we can find a solution for > this prefix-issue now. Maybe not a solution, which is optimal for all > cases, but a solution, everyone can live with. My position is essentially along these lines. Prefixes are very, very good for a large number of people, inconvenient for a small number, and a big problem for a handful. Those with big problems adapting to prefixes will have those same big problems a year from now when we definitely add prefixes, perhaps even worse problems if they have written code that interfaces directly with DBMail's tables, and which will be in more widespread use a year hence. > >> Point releases are maintennance releases. People will expect > >> regular maintennance releases, however the initial release of a new > >> version should contain most of the drastic changes that have been > >> discussed on this list for the past couple of months. > > Again, this is just a matter of preference. > Would you call the release of Linux kernel 2.6 a maintenance release? > > The developers are putting hard work into dbmail 2 for almost a year > now. I think the community of dbmail users eagerly awaits a 2.0 release > with all these improvements. I personally do not want to wait for a > bunch of *new* features to be implemented. I fear that dbmail has > already lost users in all these months, because it could not provide a > new "feature release". It is a short-lived business. I very much agree -- we're not going to be able to fit everything we want for 2.x into 2.0. The point releases will all be at the micro level, with 2.0.y for bug fixes, 2.x for added features and 2.x.y for bug fixes thereafter. That said, it is critical that we "set ourselves up for success" -- so my biggest project during the past two weeks was completely rewriting the command line processing for every one of the DBMail binaries, and rewriting the man pages to match them. Yet there's been perhaps two posts about that. But the table prefixes have caused shouts of grief and anger. I'm confused. With respect to the Linux kernel, it is actually the ABI which is the major version. If you compile something under Linux 1.x, it absolutely will not run on Linux 2.x. If you compile something under Linux 2.0, it will most likely run without a hitch on 2.2, 2.4 and 2.6. This is because the common binary interfaces to the kernel changed between 1.x and 2.x, but not between 2.x's. Aaron -- _______________________________________________ Dbmail-dev mailing list Dbmail-dev@dbmail.org http://twister.fastxs.net/mailman/listinfo/dbmail-dev
