Re: 2.1.1 tarballs posted...

At 01:22 AM 11/20/2004, Justin Erenkrantz wrote: >--On Saturday, November 20, 2004 12:53 AM -0600 "William A. Rowe, Jr." <[EMAIL >PROTECTED]> wrote: > >"Alpha indicates that the release is not meant for mainstream usage or may >have serious problems that prohibits its use. When a release is initi

Re: 2.1.1 tarballs posted...

On Sat, 20 Nov 2004, William A. Rowe, Jr. wrote: > 2.1.1 is nothing (yet) > 3 +1's (more +1 than -1) becomes alpha release. > 3 +1's (more +1 than -1) alpha becomes beta. > That beta becomes a perfect branch point for 2.2 GA. Consensus at the conference was that the branch point corresponds t

Re: 2.1.1 tarballs posted...

--On Saturday, November 20, 2004 12:53 AM -0600 "William A. Rowe, Jr." <[EMAIL PROTECTED]> wrote: 2.1.1 is nothing (yet) 3 +1's (more +1 than -1) becomes alpha release. 3 +1's (more +1 than -1) alpha becomes beta. That beta becomes a perfect branch point for 2.2 GA. Not quite. It's alpha now

Re: 2.1.1 tarballs posted...

At 12:14 AM 11/20/2004, Justin Erenkrantz wrote: > > >Grab the 2.1.1 tarballs while they're fresh. Please start testing these >releases - they should have the intent of becoming the beginning of the 2.2.x >series modulo all of the cleanup work we'll have to do

Re: People still using v1.3 - finding out why

On Fri, 19 Nov 2004, Peter Friend wrote: > I don't work in the same group anymore, so I am not sure where we are > with the 2. versions. I do know that we have large number of custom > hacks in there, including one I did many moons ago for supporting > hundreds of thousands of name based virtual h

Re: 2.1.1 tarballs posted...

Justin Erenkrantz wrote: Grab the 2.1.1 tarballs while they're fresh. Please start testing these releases - they should have the intent of becoming the beginning of the 2.2.x series modulo all of the cleanup work we'll have to do after we branch. For now, 2.

2.1.1 tarballs posted...

Grab the 2.1.1 tarballs while they're fresh. Please start testing these releases - they should have the intent of becoming the beginning of the 2.2.x series modulo all of the cleanup work we'll have to do after we branch. For now, 2.1.1 includes APR/APR-util

Re: 2.2 roadmap with respect to APR was Re: [NOTICE] CVS to SVN migration complete

At 11:03 PM 11/19/2004, Justin Erenkrantz wrote: >--On Friday, November 19, 2004 8:01 PM -0600 "William A. Rowe, Jr." <[EMAIL >PROTECTED]> wrote: > >>I'll offer compelling argument. Allen offered patches, which >>Roy vetoed, to fix object sizes on 32/64/64 ILP bit platforms, >>and told Allen to g

2.2 roadmap with respect to APR was Re: [NOTICE] CVS to SVN migration complete

--On Friday, November 19, 2004 8:01 PM -0600 "William A. Rowe, Jr." <[EMAIL PROTECTED]> wrote: I'll offer compelling argument. Allen offered patches, which Roy vetoed, to fix object sizes on 32/64/64 ILP bit platforms, and told Allen to go back and fix APR. That is the right answer, branch APR 1

Re: More informative SVN subject line (Re: svn commit: r76284 - apr/apr/trunk)

--On Friday, November 19, 2004 6:22 PM -0800 "Roy T. Fielding" <[EMAIL PROTECTED]> wrote: I happen to agree that the commit messages suck, but the right thing to do is have a look at the script and suggest a patch on the infrastructure mailing list. I would do it myself, but have a paper

Re: [NOTICE] CVS to SVN migration complete

At 06:52 PM 11/19/2004, Justin Erenkrantz wrote: >--On Saturday, November 20, 2004 1:49 AM +0100 André Malo <[EMAIL PROTECTED]> >wrote: > >>Just a question: >>Maybe I'm missing the info - is the httpd trunk supposed to work with the >>apr 1.0.x branch or just the apr trunk? > >We're going to have

Re: More informative SVN subject line (Re: svn commit: r76284 - apr/apr/trunk)

I happen to agree that the commit messages suck, but the right thing to do is have a look at the script and suggest a patch on the infrastructure mailing list. I would do it myself, but have a paper to write first. I also think that placement of the Log text after the long list of files is obviou

Re: [NOTICE] CVS to SVN migration complete

--On Saturday, November 20, 2004 1:49 AM +0100 André Malo <[EMAIL PROTECTED]> wrote: Just a question: Maybe I'm missing the info - is the httpd trunk supposed to work with the apr 1.0.x branch or just the apr trunk? We're going to have to decide which APR branch/release httpd 2.1/2.2 should work

Re: [NOTICE] CVS to SVN migration complete

* Sander Striker <[EMAIL PROTECTED]> wrote: > Hi everyone, > > The CVS to SVN conversion of the Apache HTTP Server projects is > complete. Just a question: Maybe I'm missing the info - is the httpd trunk supposed to work with the apr 1.0.x branch or just the apr trunk? nd -- die (eval q-qq:Jus

Re: Event MPM - CLOSE_WAITs

Greg Ames wrote: I have Paul's version of the Event MPM patch up and running. The only glitch I saw bringing it up was a warning for two unused variables in http_core.c (patchlet below). Then I tried stressing it with SPECweb99 and saw some errors after several minutes: [error] (24)Too many

Re: mod_rewrite functional patch

* Christian Parpart <[EMAIL PROTECTED]> wrote: > > Actually you don't need to patch httpd-2.0 for *that*. You can write a > > small module, which registers the mapper function at runtime. > > This is a way to much overhead, just for this function, isn't it? Given the fact, that the 2.0 architect

Event MPM - CLOSE_WAITs

I have Paul's version of the Event MPM patch up and running. The only glitch I saw bringing it up was a warning for two unused variables in http_core.c (patchlet below). Then I tried stressing it with SPECweb99 and saw some errors after several minutes: [error] (24)Too many open files: apr_s

Re: More informative SVN subject line (Re: svn commit: r76284 - apr/apr/trunk)

Brad Nicholes wrote: I'm sure that last thing that you want to hear is another complaint after all of the work you have gone to, but I'm not sure just listing directories is a better compromise. At least before I could see the difference between CHANGES and STATUS, now I just see "trunk" which

Re: RFC for a Perchild-like-MPM

> Ivan Ristic, Friday, November 19, 2004 12:42 > > Leif W wrote: > >>Andrew Stribblehill, Thursday, November 18, 2004 07:53 > >> > >>Quoting Ivan Ristic <[EMAIL PROTECTED]> (2004-11-17 17:31:39 GMT): > >> > >>>Paul Querna wrote: > >>> > >>> Are you familiar with FastCGI? My first impression is tha

Re: mod_rewrite functional patch

On Friday 19 November 2004 10:36 pm, André Malo wrote: > * Christian Parpart <[EMAIL PROTECTED]> wrote: > > I recently installed MediaWiki [1] (as used and developed on/by > > WikiPedia [2]). This wiki software allows an intuitive use of URLs > > as long as the host admin has patched his apache to

Re: More informative SVN subject line (Re: svn commit: r76284 - apr/apr/trunk)

I understand about the revision numbers and I agree that it is an important piece of information, but unnecessary on the subject line. The subject line needs to include information that allows one to quickly sort and prioritize the commits. IMHO, the revision number isn't a piece of information

Re: More informative SVN subject line (Re: svn commit: r76284 - apr/apr/trunk)

--On Friday, November 19, 2004 2:41 PM -0700 Brad Nicholes <[EMAIL PROTECTED]> wrote: listings to keep the subject line shorter and more informative. I also don't need to see "svn commit: r" at the front of every message. I already know it is an SVN commit based on the mailing list it came

More informative SVN subject line (Re: svn commit: r76284 - apr/apr/trunk)

I'm sure that last thing that you want to hear is another complaint after all of the work you have gone to, but I'm not sure just listing directories is a better compromise. At least before I could see the difference between CHANGES and STATUS, now I just see "trunk" which could be any one of a

Re: mod_rewrite functional patch

* Christian Parpart <[EMAIL PROTECTED]> wrote: > I recently installed MediaWiki [1] (as used and developed on/by > WikiPedia [2]). This wiki software allows an intuitive use of URLs > as long as the host admin has patched his apache to allow the > proper rewrite rules [3]. > > As Gentoo is about

mod_rewrite functional patch

Hi, I recently installed MediaWiki [1] (as used and developed on/by WikiPedia [2]). This wiki software allows an intuitive use of URLs as long as the host admin has patched his apache to allow the proper rewrite rules [3]. As Gentoo is about to support this software, we cannot expect every host

Re: SVN usage, log message policy

http://svn.collab.net/repos/svn/trunk/HACKING At 01:24 PM 11/19/2004, Sander Striker wrote: >Hi guys, > >Now that we are using SVN, would we want to adopt a guideline >for log messages. The SVN project itself uses a standard format >for all their log messages and I must say that it has helped >me

Re: ErrorHeader directive and CHANGES

> In this case, I think, no. It's clearly stated in 2.0, that's a backport from > the development branch (since it were different changes to the code base). ok. it still feels a little strange to talk about something that was both (re)added and removed between releases, since the net change is n

Re: [NOTICE] CVS to SVN migration complete

At 01:13 PM 11/19/2004, Sander Striker wrote: >Hi everyone, > >The CVS to SVN conversion of the Apache HTTP Server projects is >complete. Committers will note their cvs diff of the now-locked repository will blow up for failure to create your lockfile... to rescue your deltas, use; cvs -d :pser

SVN usage, log message policy

Hi guys, Now that we are using SVN, would we want to adopt a guideline for log messages. The SVN project itself uses a standard format for all their log messages and I must say that it has helped me tremendously when doing reviews. See http://svn.collab.net/repos/svn/HACKING for details (look fo

Re: People still using v1.3 - finding out why

I don't work in the same group anymore, so I am not sure where we are with the 2. versions. I do know that we have large number of custom hacks in there, including one I did many moons ago for supporting hundreds of thousands of name based virtual hosts without having to enter them in the confi

Re: CVS to SVN conversion

On Fri, 2004-11-19 at 11:04, Justin Erenkrantz wrote: > --On Friday, November 19, 2004 7:57 PM +0100 André Malo <[EMAIL PROTECTED]> > wrote: > > > Looks basically fine. I'm wondering a bit about the tags directory, > > especially the 1.3 subdir. Is it necessary, is there something broken? > > Ju

[NOTICE] CVS to SVN migration complete

Hi everyone, The CVS to SVN conversion of the Apache HTTP Server projects is complete. To check out your project: apache 1.3: $ svn co http://svn.apache.org/repos/asf/httpd/httpd/branches/1.3.x \ apache-1.3 httpd 2.0: $ svn co http://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x \

RE: People still using v1.3 - finding out why

We continue to have 1.3 servers because the Enhydra Director module, needed for Enydra Application Server version 3, has not been ported to Apache 2. The reason is that the Enhydra folks have long since abandoned the protocol and now use AJP13, for which there is already mod_jk2 and the AJP13 pro

Re: CVS to SVN conversion

--On Friday, November 19, 2004 7:57 PM +0100 André Malo <[EMAIL PROTECTED]> wrote: Looks basically fine. I'm wondering a bit about the tags directory, especially the 1.3 subdir. Is it necessary, is there something broken? Just to be clear, Sander's email that you are replying to was an artifact

Re: CVS to SVN conversion

* Sander Striker <[EMAIL PROTECTED]> wrote: > Hi again, > > The actual load seems to be working now (save the documentation...). > Given that this wasn't a smooth ride, we've loaded things in the > test repository. Please take a look at it: > > http://svn.apache.org/repos/test/httpd/ > > If

Re: CVS to SVN conversion

* Jim Jagielski <[EMAIL PROTECTED]> wrote: > I would like to publicly THANK Sander and Justin for their > tireless (well, not literally tireless, because they worked > so long that they were *very* tired) work in doing the > conversion! > > I think during AC2004 everyone settled their beer scores

Re: ErrorHeader directive and CHANGES

* Geoffrey Young <[EMAIL PROTECTED]> wrote: > we have the following entries in CHANGES under 2.1-dev: > > *) Drop the ErrorHeader directive which turned out to be a misnomer. > Instead there's a new optional flag for the Header directive > ('always'), which keeps the former ErrorHeade

Re: RFC for a Perchild-like-MPM

Leif W wrote: >>Andrew Stribblehill, Thursday, November 18, 2004 07:53 >> >>Quoting Ivan Ristic <[EMAIL PROTECTED]> (2004-11-17 17:31:39 GMT): >> >>>Paul Querna wrote: >>> >>> Are you familiar with FastCGI? My first impression is that most of >>> what you envision is possible today with FastCGI,

Syncing access to socreboard

Hi, Does anyone has idea how to protect the access to the scoreboard? Does apache 2.1 has some global lock that can be used for that (with public api perhaps)? Regards, Mladen.

Re: Fwd: Re: [PROPOSAL-VOTE] Adopt lazy consensus for backports...

At 05:41 PM 11/18/2004, Astrid Keßler wrote: >> IMHO a better way bring the development further is the suggestion on the dev >> list. *absolute* feature freeze on stable branches (except 1.3?), bug fixes >> only. Though it would need some time to establish the trust of the community >> in so much

ErrorHeader directive and CHANGES

hi all... we have the following entries in CHANGES under 2.1-dev: *) Drop the ErrorHeader directive which turned out to be a misnomer. Instead there's a new optional flag for the Header directive ('always'), which keeps the former ErrorHeader functionality. [André Malo] *) mod

Re: RFC for a Perchild-like-MPM

> Andrew Stribblehill, Thursday, November 18, 2004 07:53 > > Quoting Ivan Ristic <[EMAIL PROTECTED]> (2004-11-17 17:31:39 GMT): > > Paul Querna wrote: > > > > Are you familiar with FastCGI? My first impression is that most of > > what you envision is possible today with FastCGI, or would be > >

Re: [PROPOSAL-VOTE] Adopt lazy consensus for backports...

Let's look at it this way. 2.1 is CTR whereas 2.0 is RTC. This applies to backports. However, the Review for most backports is "already done" within the 2.1 CTR cycle. If the original has been in 2.1 for a "significant" amount of time, it implies review. So the required review for that backport in

fails to inherit per_dir_config on 1.3

I'm not sure whether this is a bug or a feature, but I've found myself needing to combine ProxyPass with http authentication on a legacy Apache 1.3 box (which I'm unfortunately not in a position to upgrade to Apache 2 yet). If I specify something like: ProxyRequests off ProxyPass / http://localh

Re: CVS to SVN conversion

On Nov 17, 2004, at 4:45 PM, Sander Striker wrote: Hi again, The actual load seems to be working now (save the documentation...). Given that this wasn't a smooth ride, we've loaded things in the test repository. Please take a look at it: http://svn.apache.org/repos/test/httpd/ If noone raises an

Re: PCRE in 2.1/2.2

On Wed, Nov 17, 2004 at 05:01:48PM -0800, Brian Pane wrote: > About two years ago, I made some performance optimizations to the copy > of pcre in the httpd-2.0 tree. I submitted the diffs to the pcre > maintainer, but I don't know if they've made it into a subsequent pcre > release. Yep, these ha

Re: People still using v1.3 - finding out why

On Thu, 18 Nov 2004 13:43:17 -0600, Graham Leggett <[EMAIL PROTECTED]> wrote: >Apart from backhand, > are there > in the experience of the people on this list any other significant apps > out there that are keeping people from deploying http

Re: RFC for a Perchild-like-MPM

Max Bowsher wrote: >>> Quoting Ivan Ristic (2004-11-17 17:31:39 GMT): >>> I've used FastCGI to give individual users their own PHP engines (since PHP now comes with FastCGI protocol support built-in). > > > This sounds useful - would you be willing to share some config file >

Re: People still using v1.3 - finding out why

Hi, another reason may be mod_perl, althought mod_perl 2.0 is available for quite some time, and there is a good documentation how to migrate applications, many applications based on mod_perl haven't done so. The problem is not the same as for mod_php. mod_php 4.* has been available for apache

CVS to SVN conversion

Hi again, The actual load seems to be working now (save the documentation...). Given that this wasn't a smooth ride, we've loaded things in the test repository. Please take a look at it: http://svn.apache.org/repos/test/httpd/ If noone raises any issues we'll load it in the main repository in