APACHE 2.1 STATUS: -*-text-*-
Last modified at [$Date: 2004/11/06 08:28:24 $]
Release [NOTE that only Alpha/Beta releases occur in 2.1 development]:
2.1.1 : Proposed roll on 11/14/2004 (around/after Hackathon).
Justin volunteers as
APACHE 2.0 STATUS: -*-text-*-
Last modified at [$Date: 2004/11/10 18:05:46 $]
Release:
2.0.53 : in development
2.0.52 : released September 28, 2005 as GA.
2.0.51 : released September 15, 2004 as GA.
2.0.50 : released June 30, 2004 a
APACHE 1.3 STATUS: -*-text-*-
Last modified at [$Date: 2004/10/30 13:20:38 $]
Release:
1.3.34-dev: In development.
1.3.33: Tagged October 27, 2004
1.3.32: Tagged October 18, 2004. Not formally released.
1.3.31: Tagged May 7, 2004. Announc
Greetings All,
Attached and listed below are two NWGNUmakefiles plus diff's to add them
into to the httpd build processdisavow being a wiz at this stuff and
if someone doesn't like the names chosen, etc here's the chance to
supply something better (the prod)... :-)
For .\experimental\mod_fi
William A. Rowe, Jr. wrote:
At 01:29 PM 11/24/2004, Cliff Woolley wrote:
On Wed, 24 Nov 2004, Justin Erenkrantz wrote:
I'm sick of all talk and no action. We tried this last year when we were
"almost" ready to branch APR 1.0 and all action on that front ceased
entirely for a YEAR. This time it's
At 01:29 PM 11/24/2004, Cliff Woolley wrote:
>On Wed, 24 Nov 2004, Justin Erenkrantz wrote:
>
>I'm sick of all talk and no action. We tried this last year when we were
>"almost" ready to branch APR 1.0 and all action on that front ceased
>entirely for a YEAR. This time it's one or the other. I'l
At 01:05 PM 11/24/2004, Cliff Woolley wrote:
>On Wed, 24 Nov 2004, William A. Rowe, Jr. wrote:
>
>> Allan - your last patches were to try to -wedge- the current
>> API into httpd. Can you share the patch just to fix APR?
>> Then we can start to comprehend scope. NO CASTS - just the
>> correct dec
On Wed, 24 Nov 2004, Justin Erenkrantz wrote:
> To be clear, I'm perfectly happy with merging to trunk in Allen's changes
> *once* completed and reviewed and moving trunk to 2.x if need be - but I
Nevertheless, the question at hand is what action to take RIGHT NOW.
"Let's just wait for..." with
--On Wednesday, November 24, 2004 2:29 PM -0500 Cliff Woolley
<[EMAIL PROTECTED]> wrote:
I'm sick of all talk and no action. We tried this last year when we were
"almost" ready to branch APR 1.0 and all action on that front ceased
entirely for a YEAR. This time it's one or the other. I'll wait
On Wed, 24 Nov 2004, Justin Erenkrantz wrote:
> Oh, please don't. We have *no* idea what the changes are or whether we'll
> even ultimately accept them. Please branch Allen's changes off in a
> sandbox (cp trunk branches/64-bit-changes) - let him get a workable version
> that we can then review,
Cliff Woolley wrote:
On Wed, 24 Nov 2004, Garrett Rooney wrote:
I guess I'm just arguing for a single branch that's the target of the
current development, as opposed to one 64 bit dev branch and one trunk
which holds other changes, thus requiring us to either invest constant
effort in merging chan
--On Wednesday, November 24, 2004 2:20 PM -0500 Cliff Woolley
<[EMAIL PROTECTED]> wrote:
So sure, screw it. APR trunk is now 2.0-dev. Have fun.
Oh, please don't. We have *no* idea what the changes are or whether we'll
even ultimately accept them. Please branch Allen's changes off in a
sandb
On Wed, 24 Nov 2004, Garrett Rooney wrote:
> I guess I'm just arguing for a single branch that's the target of the
> current development, as opposed to one 64 bit dev branch and one trunk
> which holds other changes, thus requiring us to either invest constant
> effort in merging changes from the
Cliff Woolley wrote:
On Wed, 24 Nov 2004, William A. Rowe, Jr. wrote:
Allan - your last patches were to try to -wedge- the current
API into httpd. Can you share the patch just to fix APR?
Then we can start to comprehend scope. NO CASTS - just the
correct declarations in the first place.
Since t
On Wed, 24 Nov 2004, William A. Rowe, Jr. wrote:
> Allan - your last patches were to try to -wedge- the current
> API into httpd. Can you share the patch just to fix APR?
> Then we can start to comprehend scope. NO CASTS - just the
> correct declarations in the first place.
Since this is obviou
At 12:29 PM 11/24/2004, Allan Edwards wrote:
>If we can make good progress towards a stable 64 bit APR 2.0 then
>moving httpd 2.1/2.2 to it could make sense. The question is
>whether there is enough feature freeze pressure to say that
>64 bit does not warrant the wait...
Allan - your last patches
On Wed, 24 Nov 2004, Allan Edwards wrote:
> First order of business now that we are on SVN is to focus on
> the APR changes that are needed. It's not clear to me though,
> now that we have an APR 1.0 branch, is the trunk open for
> API-breaking changes or do we need a separate branch for that work
man, how did I get so far behind on my email...
I'd like to see us get this into httpd 2.2 for the reasons
previously outlined and think we need to get the work underway
as quickly as possible to determine how extensive the changes
are going to be and how fast progress can be made.
First order of b
* Yoshiki Hayashi <[EMAIL PROTECTED]> wrote:
> ++1. I'm ready to help, too. I was playing with web site
> documentation to start providing translation of those pages
> and wondered why we haven't moved to CSS yet.
Just wanted to let you know: I've talked to the guy, who made a lot of base
desig
* Yoshiki Hayashi <[EMAIL PROTECTED]> wrote:
> After conversion is done, sending out instruction of how to
> update existing checkout would be nice. I believe you can
> just "svn switch" to the new location but I'm not sure.
yep. just `svn switch new-url`
nd
--
"Das Verhalten von Gates hatte m
Justin Erenkrantz wrote:
>
> --On Tuesday, November 23, 2004 7:54 PM -0500 Jim Jagielski <[EMAIL
> PROTECTED]>
> wrote:
>
> > One thing I was hoping is that, if bundled it, people can
> > add the kind of features they need. It was designed for a
> > simple and clear purpose, but there is more t
Nick Kew wrote:
>
> Would mod_filter be a Good Place for new diagnostic
> (FilterTrace) modes anyone needs to add, if it were extended to deal
> with input filters too?
>
I don't think so. I don't think having to implement/add all
the complexity and overhead of mod_filter just when you
want to b
--On Wednesday, November 24, 2004 6:01 AM -0500 Jeff Trawick
<[EMAIL PROTECTED]> wrote:
Thanks! (Gosh Justin, I'm so envious of your free time. I can't keep
up with my in-box.)
I wish it'd be s/free/sleep/. =) -- justin
On Wed, 24 Nov 2004 01:43:43 -0800, Justin Erenkrantz
<[EMAIL PROTECTED]> wrote:
> --On Wednesday, November 24, 2004 9:12 AM + Joe Orton <[EMAIL PROTECTED]>
> wrote:
>
> > The http://svn.apache.org/viewcvs.cgi?rev=106264&view=rev link will
> > catch everything though, right?
>
> See the commi
Bill Stoddard wrote:
Brian Pane wrote:
Paul Querna wrote:
Paul Querna wrote:
> A thread per-connection that is currently being processed.
Yeah, SEDA's model of processing "stages"--basically a succession of
thread pools through
which a request passes, each with a queue in front--looks like a
pro
--On Wednesday, November 24, 2004 9:12 AM + Joe Orton <[EMAIL PROTECTED]>
wrote:
The http://svn.apache.org/viewcvs.cgi?rev=106264&view=rev link will
catch everything though, right?
See the commit email for r106402... =) -- justin
On Wed, Nov 24, 2004 at 01:04:18AM -0800, Justin Erenkrantz wrote:
> --On Wednesday, November 24, 2004 8:58 AM + Joe Orton
> <[EMAIL PROTECTED]> wrote:
>
> >9 out of 10 mutt users prefer URLs which don't line-wrap :)
>
> For the record, the reason why the URL is so long is because a file mig
--On Wednesday, November 24, 2004 8:58 AM + Joe Orton <[EMAIL PROTECTED]>
wrote:
9 out of 10 mutt users prefer URLs which don't line-wrap :)
For the record, the reason why the URL is so long is because a file might
exist in one revision, but not in another. I guess I could enhance the
mail
On Wed, Nov 24, 2004 at 01:56:38AM -, Jeff Trawick wrote:
> Author: trawick
> Date: Tue Nov 23 17:56:37 2004
> New Revision: 106369
>
> Modified:
>httpd/httpd/branches/2.0.x/STATUS
> Log:
> that's some URL
I think for backports it will be OK to just reference the revision URL
in ViewCVS e
On Tue, 23 Nov 2004, Cliff Woolley wrote:
> But mod_dumpio calls apr_bucket_read() unconditionally on data buckets,
> which is exactly what I *don't* want it to do. Because that modifies the
> contents of the brigade. The module I'm looking for needs to be
> completely transparent. But it's a v
30 matches
Mail list logo