httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jerenkra...@ebuilt.com>
Subject General Availability release qualities?
Date Sat, 08 Sep 2001 18:33:48 GMT
Since a lot of people on-list are starting to make noise about
rejecting feature changes because we are close to releasing
Apache 2.0, I would like to ask what are the outstanding issues
that must be addressed before we release Apache 2.0 as GA?

As a starting point, my personal items are as follows:

- Completely remove threaded MPM and replace it with worker.  I do
  not think that the current threaded MPM can work (due to discussions
  held on this list previously).  The worker MPM (which Aaron has been 
  making progress towards) should act as a replacement MPM.  I know
  that Aaron has some patches that he has tested that make it faster
  than prefork.  I look forward to seeing those patches make it in
  and fully tested.

- Get the APR lock situation straightened out.  This means converting
  the old lock API to the new one.  (This probably means that APR
  needs to at least be beta by the time we release httpd as GA - other
  than the locks, I don't see that as a major problem.  I don't want
  to have any major API changes after we hit GA - the lock API is a
  fairly major API in APR.)

- Get mod_ssl stable - which at this point, requires testing it.
  I was under the (false) impression that mod_ssl wasn't going to 
  hold up any releases.  Since OtherBill said that isn't true, 
  let's make sure it is rock solid.  This probably means that 
  we need to get a few beta-quality tarballs before going GA.
 
- Resolve the proxy situation.  A lot of committers (FirstBill
  comes to mind) would like to see this come back in the core.  
  If it is ready and the group consensus is to add it, then let's
  add it back in before GA.
 
- Make sure that the recent optimizations in mod_include didn't
  bust anything.  I don't think it did (otherwise, I wouldn't have
  committed it), but it does need to be tested.  We can probably
  strengthen the tests in httpd-test to create bucket border cases.

- Straighten out the filter config syntax as OtherBill and I have 
  suggested.  I think that the current syntax is too confusing and
  not powerful enough.  Once we release httpd-2.0 as a GA, I don't 
  think we can make any configuration syntax changes.  So, this 
  would have to go in before we hit GA.

- Verify the bucket/brigade API and potentially try to address the
  memory usage concerns (get it not to do malloc/free on small 
  chunks).  AIUI, Cliff is working towards this.

- Update the documentation to be as current as we can make it.  I
  think that the docs are fairly up-to-date, but we need to make
  sure that the docs are just as solid as the code.  

- I would like to see performance with Apache 2.0 equal or surpass
  the performance of Apache 1.3.  However, I'm not entirely sure
  that will happen before we can release (if you want to do so in
  45 days as some have suggested).  Given that that may not be the
  case, I'd like it to be as close as possible.  In the last few
  weeks, we've definitely made strides towards improving our
  performance (especially in mod_include - thanks to Brian and Ian).
  In the subsequent point releases, we can continue to address the 
  overall performance and attempt to make 2.1 faster than 1.3.  
  However, if 2.0 isn't faster than Apache 1.3, I wonder how many 
  people will adopt it (however, most sites are bandwidth limited, 
  so I'm not sure if this is a concern).  Therefore, I think we 
  need to come to a consensus about our take on the performance of 
  Apache 2.0 relative to Apache 1.3.  Is it a requirement that 
  Apache 2.0 must be as fast as Apache 1.3 before we hit GA?  

I believe that our current tree status is at a beta-quality level.  
And, I think we can start to see the light at the end of the tunnel
(and are anxious to get this released and out the door).  People 
can use it, but I'm not entirely sure that I would call what we 
have as being rock-solid as Apache 1.3.

Before we release a GA build, I believe *we* have to believe that it 
is a substantially better and as reliable a product as Apache 1.3 
(which is a very hard product to beat).  This doesn't mean that
there aren't any bugs with it - it's just that we know of *zero* 
bugs in the tree after receiving all of the feedback from the 
community, testers, and our own use.

I would like to ensure that any GA is ready and that we can 
encourage any site admin who runs Apache 1.3 that they can upgrade 
to 2.0 without any loss in functionality or stability (provided
that their modules are ported properly).

As most of you know (like I haven't said it enough), I'm going to be 
out of regular email contact for a few weeks.  But, I hope this 
enlightens you on my perspective on what should happen before a 
GA is released.  I look forward to seeing any replies and thoughts 
before I leave tomorrow (please continue this thread even if I can't
reply!).  

"How do we know when we get there if we don't know where we're going?"

Once classes start again and I get settled in my new place, I'll 
resume active development.  -- justin


Mime
View raw message