Return-Path: Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 46799 invoked by uid 500); 8 Sep 2001 18:34:12 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 46788 invoked from network); 8 Sep 2001 18:34:12 -0000 Date: Sat, 8 Sep 2001 11:33:48 -0700 From: Justin Erenkrantz To: dev@httpd.apache.org Subject: General Availability release qualities? Message-ID: <20010908113348.P2482@ebuilt.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-AntiVirus: scanned for viruses by AMaViS 0.2.1-pre3 (http://amavis.org/) X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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