httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <>
Subject Re: Apache 2000, err Apache 2.0 gets real
Date Sat, 31 Jul 1999 22:18:24 GMT
>It's time to create Apache 2.0 and begin working on our first

Uh, maybe we should try to get a working version internally first,
on all of the modern platforms.  We can talk about beta later.

My first priority is my dissertation (T minus four months and counting),
but my opinion is...

It is probably easiest to merge the 1.3.7-8 changes into mpm first,
since that will make later diffs easier.  This can be done now.

I'd like to start with a clean repository that has 1.3.8 files
as revision 1.1, but moved to the directories slated for mpm+apr.
Anything involving separating functionality into new files or splitting
header files (like httpd.h badly needs) should be done first.
This can be done as soon as Brian creates/moves the appropriate
modules on, once we figure out how to coordinate it.
I was thinking the other night that we could probably do this very
quickly if we just set up a time block to do the work and coordinate
via IRC or some other instant messaging system.

I'd then like to see each of the major change sets from the experiments
committed separately, so that there is at least some clue as to why
the changes were made.  Choose the granularity as you wish, but I don't
want changes for HOOKs mixed up with rearchitecting for MPM or portability
for APR.  It would also be nice if the hook stuff used the Apache style,
protected the global names from collisions, and included documentation,
because if it doesn't by the time it gets committed to 2.0 then I'll veto it.
Likewise, some of the unnecessary changes from the pthreads port, like
removing all the ap_block_alarms instead of just defining it as null
for threaded mpms, don't need to be brought forward right away.

After that, set up autoconf as the one and only configuration tool.
I happen to like automake as well, but I'd at least like to figure out
why Ralf isn't using it first.  Same with libtool.

Finally, begin APR'izing the rest of the code.  This is a massive change,
after which the 1.3 releases are a branch never to be merged again.

Then we start running it on our own systems.  When we have had some real
first-hand experience with it on our own production sites, we can talk
about releasing it to non-developers.

>We've discussed a lot of this in the past. So do we need a vote on this
>or can we start the work now?

Not much point in voting -- either we set up a time to do it together
or we just split up the tasks and do it separately.  A clean repository
can be built anywhere (like in my sandbox) -- we just need to tar the
rcs files over to the final location when its ready.  People not interested
in a clean repository can just keep working in the other ones.

But we can't do a clean repository based on 1.3.8 until 1.3.8 is released.
And there are a boatload of minor fixes/ports that could have been applied
last month if anyone bothered to do the culling.  Remember, that is something
that RST, RobH, myself, and Dean have done in turn, but isn't being done
by anyone at the moment.


View raw message