You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Paul Querna <ch...@force-elite.com> on 2005/08/30 06:58:12 UTC
Status of 2.1.7
I counted two votes about 2.1.7-beta:
+1: Brad, Joe
No one else put votes in the thread.
We did find several non-showstopper issues with this tag. If anyone has
a few spare minutes, it would be good to start back porting these from
trunk to the 2.2.x branch.
Thanks,
Paul
Re: Status of 2.1.7
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On August 29, 2005 9:58:12 PM -0700 Paul Querna <ch...@force-elite.com>
wrote:
> I counted two votes about 2.1.7-beta:
> +1: Brad, Joe
Passes httpd-test on Mac OS X 10.4.2.
+1 for beta. -- justin
Re: Status of 2.1.7g
Posted by r....@t-online.de.
Joe Orton wrote:
> On Tue, Aug 30, 2005 at 01:01:40PM +0100, Colm MacCarthaigh wrote:
>
>>On Mon, Aug 29, 2005 at 09:58:12PM -0700, Paul Querna wrote:
>>
>>>We did find several non-showstopper issues with this tag. If anyone has
>>>a few spare minutes, it would be good to start back porting these from
>>>trunk to the 2.2.x branch.
>
>
> dare I wonder... CTR or RTC?
>
>From my point of view RTC. I had a short discussion with Justin during offline mails
on this and he also said RTC.
Regards
Rüdiger
Re: Status of 2.1.7g
Posted by Colm MacCarthaigh <co...@stdlib.net>.
On Tue, Aug 30, 2005 at 02:47:05PM -0700, Justin Erenkrantz wrote:
> --On August 30, 2005 8:54:57 AM -0400 Jeff Trawick <tr...@gmail.com>
> wrote:
>
> >>> http://people.apache.org/~colm/2.1.7-non-showstoppers.patch
> >>
> >>+1 on all that for the 2.2.x branch in any case.
> >
> >+1 here as well
>
> +1 too on that set of changes. I think we hit RTC once the branch opens
> towards GA - which'll happen once we issue a release from it. -- justin
Just a note if anyone applies the patch; the patch is against 2.1.7, the
RPM spec change has already been applied to 2.2.x, so expect that to
fail.
Oh and use the latest roll.sh, to fix that annoying xml silliness, if
rolling a tarball :)
--
Colm MacCárthaigh Public Key: colm+pgp@stdlib.net
Re: Status of 2.1.7g
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On August 30, 2005 8:54:57 AM -0400 Jeff Trawick <tr...@gmail.com>
wrote:
>> > http://people.apache.org/~colm/2.1.7-non-showstoppers.patch
>>
>> +1 on all that for the 2.2.x branch in any case.
>
> +1 here as well
+1 too on that set of changes. I think we hit RTC once the branch opens
towards GA - which'll happen once we issue a release from it. -- justin
Re: Status of 2.1.7g
Posted by Jeff Trawick <tr...@gmail.com>.
On 8/30/05, Joe Orton <jo...@redhat.com> wrote:
> On Tue, Aug 30, 2005 at 01:01:40PM +0100, Colm MacCarthaigh wrote:
> > On Mon, Aug 29, 2005 at 09:58:12PM -0700, Paul Querna wrote:
> > > We did find several non-showstopper issues with this tag. If anyone has
> > > a few spare minutes, it would be good to start back porting these from
> > > trunk to the 2.2.x branch.
>
> dare I wonder... CTR or RTC?
>
> > http://people.apache.org/~colm/2.1.7-non-showstoppers.patch
>
> +1 on all that for the 2.2.x branch in any case.
+1 here as well
Re: Status of 2.1.7g
Posted by Joe Orton <jo...@redhat.com>.
On Tue, Aug 30, 2005 at 01:01:40PM +0100, Colm MacCarthaigh wrote:
> On Mon, Aug 29, 2005 at 09:58:12PM -0700, Paul Querna wrote:
> > We did find several non-showstopper issues with this tag. If anyone has
> > a few spare minutes, it would be good to start back porting these from
> > trunk to the 2.2.x branch.
dare I wonder... CTR or RTC?
> http://people.apache.org/~colm/2.1.7-non-showstoppers.patch
+1 on all that for the 2.2.x branch in any case.
> Fixes;
> * mod_setenvif orphaned documentation
> * server/listen.c so that it works on AIX
> * build/rpm/httpd.spec.in to work
> * support/htcacheclean.c to work
>
> Doesn't fix the PCRE build problem though, couldn't find a clear
> decision on whether bundling a newer PCRE or patching was preferred.
The PCRE -DDEBUG thing is very obscure, it's not worth patching. It can
just wait until someone gets a round tuit and upgrades to a newer pcre
release since Sander says it's fixed upstream now.
joe
Re: Status of 2.1.7g
Posted by Colm MacCarthaigh <co...@stdlib.net>.
On Mon, Aug 29, 2005 at 09:58:12PM -0700, Paul Querna wrote:
> We did find several non-showstopper issues with this tag. If anyone has
> a few spare minutes, it would be good to start back porting these from
> trunk to the 2.2.x branch.
http://people.apache.org/~colm/2.1.7-non-showstoppers.patch
Fixes;
* mod_setenvif orphaned documentation
* server/listen.c so that it works on AIX
* build/rpm/httpd.spec.in to work
* support/htcacheclean.c to work
Doesn't fix the PCRE build problem though, couldn't find a clear
decision on whether bundling a newer PCRE or patching was preferred.
--
Colm MacCárthaigh Public Key: colm+pgp@stdlib.net
Re: Status of 2.1.7
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On August 30, 2005 10:46:01 PM +0100 Colm MacCarthaigh <co...@stdlib.net>
wrote:
> Since Apachecon EU, it's also been running the worker MPM (on IA64). and
> performance is up by around 9% in our benchmarks. In trunk's STATUS
> there's a vote which seems have long since passed (positively) to make
> worker the default MPM.
>
> Is this going to happen for 2.2 GA?
Given the problems with Solaris 10 and worker MPM, I'm inclined to say that
such a default change missed the boat for 2.2. Hence, it'll need to wait
for 2.4. (Hopefully, it won't take us another 3 years to do a minor
release!) -- justin
Re: Status of 2.1.7
Posted by Colm MacCarthaigh <co...@stdlib.net>.
On Wed, Aug 31, 2005 at 12:10:33AM +0200, r.pluem@t-online.de wrote:
> > Yep, and it's faster, by about 9%. We've also done some other crazy
> > things;
>
> What is the ThreadsPerChild setting you use?
currently using;
<IfModule worker.c>
ServerLimit 900
StartServers 200
MaxClients 28800
MinSpareThreads 25
MaxSpareThreads 75
ThreadsPerChild 32
</IfModule>
> > And probably this week we're going to switch to the event MPM. it's
> > currently being tested with 100 million requests to see if there are any
> > low-hanging epoll() bugs.
>
> It will be interesting to hear how it behaves regarding performance and
> stability once you have it on ftp.heanet.ie.
Well it originally took a few months to get worker working on
ftp.heanet.ie, so it's already ahead ;)
--
Colm MacCárthaigh Public Key: colm+pgp@stdlib.net
Re: Status of 2.1.7
Posted by r....@t-online.de.
Colm MacCarthaigh wrote:
> On Tue, Aug 30, 2005 at 11:54:04PM +0200, r.pluem@t-online.de wrote:
>
[..cut..]
> Yep, and it's faster, by about 9%. We've also done some other crazy
> things;
What is the ThreadsPerChild setting you use?
>
> http://www.linux.ie/lists/pipermail/ilug/2005-August/028571.html
Thanks for the update.
>
> And probably this week we're going to switch to the event MPM. it's
> currently being tested with 100 million requests to see if there are any
> low-hanging epoll() bugs.
It will be interesting to hear how it behaves regarding performance and
stability once you have it on ftp.heanet.ie.
[..cut..]
Regards
Rüdiger
Re: Status of 2.1.7
Posted by Colm MacCarthaigh <co...@stdlib.net>.
On Tue, Aug 30, 2005 at 11:54:04PM +0200, r.pluem@t-online.de wrote:
> > Since Apachecon EU, it's also been running the worker MPM (on IA64). and
> > performance is up by around 9% in our benchmarks. In trunk's STATUS
>
> Just curious. So you switched from your prefork configuration that was presented
> during your Apachecon EU session to worker / NPTL?
Yep, and it's faster, by about 9%. We've also done some other crazy
things;
http://www.linux.ie/lists/pipermail/ilug/2005-August/028571.html
And probably this week we're going to switch to the event MPM. it's
currently being tested with 100 million requests to see if there are any
low-hanging epoll() bugs.
It doesn't help us with keepalives, but it's proving even faster again
in testing.
--
Colm MacCárthaigh Public Key: colm+pgp@stdlib.net
Re: Status of 2.1.7
Posted by r....@t-online.de.
Colm MacCarthaigh wrote:
[..cut..]
> Since Apachecon EU, it's also been running the worker MPM (on IA64). and
> performance is up by around 9% in our benchmarks. In trunk's STATUS
Just curious. So you switched from your prefork configuration that was presented
during your Apachecon EU session to worker / NPTL?
[..cut..]
Regards
Rüdiger
Re: Status of 2.1.7
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 04:46 PM 8/30/2005, Colm MacCarthaigh wrote:
>Since Apachecon EU, it's also been running the worker MPM (on IA64). and
>performance is up by around 9% in our benchmarks. In trunk's STATUS
>there's a vote which seems have long since passed (positively) to make
>worker the default MPM.
>
>Is this going to happen for 2.2 GA?
IMHO, yes it should.
Bill
Re: Status of 2.1.7
Posted by Colm MacCarthaigh <co...@stdlib.net>.
On Tue, Aug 30, 2005 at 04:22:33PM -0500, William A. Rowe, Jr. wrote:
> I'm concerned about a number of significant instability reports
> on 2.0.x, never mind 2.1.x, in bugzilla, and don't think this
> is quite ready to ship.
For what it's worth I consider the trunk branch more stable than 2.0.x.
I've been running trunk in production on ftp.heanet.ie for nearly 6
months now, with no problems.
Since Apachecon EU, it's also been running the worker MPM (on IA64). and
performance is up by around 9% in our benchmarks. In trunk's STATUS
there's a vote which seems have long since passed (positively) to make
worker the default MPM.
Is this going to happen for 2.2 GA?
--
Colm MacCárthaigh Public Key: colm+pgp@stdlib.net
Re: Status of 2.1.7
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 04:22 PM 8/30/2005, William A. Rowe, Jr. wrote:
>At 05:22 AM 8/30/2005, Jeff Trawick wrote:
>>On 8/30/05, Paul Querna <ch...@force-elite.com> wrote:
>>> I counted two votes about 2.1.7-beta:
>>> +1: Brad, Joe
>Whoops - missed the word 'beta' :)
>
>So -1 here from the peanut gallery on beta for this candidate,
>simply because most devs didn't feel strongly enough to endorse
>this beta over the last week+. Let's see if we can't find a
>candidate that folks endorse more strongly.
Some folks on IRC were confused, so let me say again -1
on *beta*, +1 for this candidate for *alpha*.
Bill
Re: Status of 2.1.7
Posted by Nick Kew <ni...@webthing.com>.
On Wednesday 31 August 2005 03:38, Justin Erenkrantz wrote:
> On Tue, Aug 30, 2005 at 09:10:25PM -0500, William A. Rowe, Jr. wrote:
> > If folks aren't voting, will they be supporting the problem reports
> > that come in?
>
> I count the following for 2.1.7 beta (Paul missed a bunch of votes):
>
> +1: Joe, Brad, Jeff, Jim, Justin.
> -1: OtherBill ('no one voted')
>
> How many folks do you think we need? -- justin
Things have moved on since 2.1.7. Bugs fixed - great. New features added
with CTR - great, but not really what we want in a Beta.
Let's make 2.1.8 a beta - including new goodies like graceful shutdown -
and at the same time move to RTC for any new features (keeping CTR
bugfixes). I'd +1 that (barring any showstopper regression).
--
Nick Kew
Re: Status of 2.1.7
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Tue, Aug 30, 2005 at 09:10:25PM -0500, William A. Rowe, Jr. wrote:
> If folks aren't voting, will they be supporting the problem reports
> that come in?
I count the following for 2.1.7 beta (Paul missed a bunch of votes):
+1: Joe, Brad, Jeff, Jim, Justin.
-1: OtherBill ('no one voted')
How many folks do you think we need? -- justin
Re: Status of 2.1.7
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 07:40 PM 8/30/2005, Paul Querna wrote:
>William A. Rowe, Jr. wrote:
>> So -1 here from the peanut gallery on beta for this candidate,
>> simply because most devs didn't feel strongly enough to endorse
>> this beta over the last week+. Let's see if we can't find a
>> candidate that folks endorse more strongly.
>
>So, this is a -1 not on technical reasons, but because other people
>haven't voted on it? I disagree on that kind of reason for a -1 vote.
First; vote +/- 1 on a release need not be technical, is _never_
a veto, and
If we are going to release a beta, we have to *support* the beta.
If folks aren't voting, will they be supporting the problem reports
that come in?
My *biggest* concerns before we announce beta again *to the world*
are that;
* we need a 2.0 -> 2.2 document. What changed? What do I have
to change in my httpd.conf? What's known to break? (As opposed
to the existing CHANGES of what is now 'unbroken').
* we need internal testers, who are obviously testing the
candidates thoroughly and promptly (voting soon after some
candidate is proposed.) We state "2.n.n is the BEST AVAILABLE
VERSION" (italics mine) - and it damned well better be :)
* we need folks to comb bugzilla for the new reports coming
in once the beta is announced, and help fix. We have a few
new committers so this will get easier. (FYI - if you are
an occasional contributor, all it takes is posts to the
dev@httpd discussing and proposing patches over an extended
period of time to become a committer. The project is looking
for committers who help with multiple interests and who show
an overall interest in the health of the httpd project.)
* we are prepared to go GA within 6-8 weeks. It's pointless
if the code isn't that far along.
Calling it an alpha, beta, or a quadrangle is worthless if we
aren't investing the effort to elicit every available tester,
and if we aren't giving them the resources they need to help
*US* get it right :)
Let's move on, 2.1.7 already collected dust.
Bill
Re: Status of 2.1.7
Posted by Paul Querna <ch...@force-elite.com>.
William A. Rowe, Jr. wrote:
> At 05:22 AM 8/30/2005, Jeff Trawick wrote:
>
>>On 8/30/05, Paul Querna <ch...@force-elite.com> wrote:
>>
>>>I counted two votes about 2.1.7-beta:
>>>+1: Brad, Joe
>>>
>>>No one else put votes in the thread.
>>
>>+1, with a strong concern that the non-showstopper issues are highlighted
>
>
> Whoops - missed the word 'beta' :)
>
> First I'm not really clear, will this go 2.2.0-beta, or will
> we keep shipping 2.1.7-beta, 2.1.8-beta, 2.1.9-beta, then
> 2.2.0-ga?
My plan it to use 2.1.XX numbers until GA. This means 2.1.8-beta,
2.1.9-beta, etc, until we vote one of these betas as GA. Once voted for
GA, it will be tagged to 2.2.0, and the first 2.2.0 release will be GA.
This is in an attempt to avoid the uncertainty that the early 2.0.xx
releases caused.
> I'm concerned about a number of significant instability reports
> on 2.0.x, never mind 2.1.x, in bugzilla, and don't think this
> is quite ready to ship.
Please be specific. I don't see many 'instability' reports. Can you
provide examples of which entries in bugzilla you are thinking of?
I don't think we are taking a step back with 2.1.x. It might not be a
step forward in every module, but it isn't getting worse than 2.0.x, and
that is the important part.
The point of beta it to get more exposure for these new features. It
does not need to be perfect, only better than the last beta.
> So -1 here from the peanut gallery on beta for this candidate,
> simply because most devs didn't feel strongly enough to endorse
> this beta over the last week+. Let's see if we can't find a
> candidate that folks endorse more strongly.
So, this is a -1 not on technical reasons, but because other people
haven't voted on it? I disagree on that kind of reason for a -1 vote.
> IIUC release voting lasts typically 3 days or so, if this vote
> stretched out this long, I'd offer that it didn't pass.
FWIW, last time I did a release voting in exactly 3 days (ARR 1.1.1),
people wanted longer. I was busy this weekend, and this was the first
chance I had to touch base with people on the voting. My choice was 3
days, or 9 days.
-Paul
Re: Status of 2.1.7
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 05:22 AM 8/30/2005, Jeff Trawick wrote:
>On 8/30/05, Paul Querna <ch...@force-elite.com> wrote:
>> I counted two votes about 2.1.7-beta:
>> +1: Brad, Joe
>>
>> No one else put votes in the thread.
>
>+1, with a strong concern that the non-showstopper issues are highlighted
Whoops - missed the word 'beta' :)
First I'm not really clear, will this go 2.2.0-beta, or will
we keep shipping 2.1.7-beta, 2.1.8-beta, 2.1.9-beta, then
2.2.0-ga?
I'm concerned about a number of significant instability reports
on 2.0.x, never mind 2.1.x, in bugzilla, and don't think this
is quite ready to ship.
So -1 here from the peanut gallery on beta for this candidate,
simply because most devs didn't feel strongly enough to endorse
this beta over the last week+. Let's see if we can't find a
candidate that folks endorse more strongly.
IIUC release voting lasts typically 3 days or so, if this vote
stretched out this long, I'd offer that it didn't pass.
And FYI, I'm not concerned with objections like 'the beta doesn't
work on Win32' for example - if enough platforms are stable, the
next beta will work on more of them.
Bill
Re: Status of 2.1.7
Posted by Jeff Trawick <tr...@gmail.com>.
On 8/30/05, Paul Querna <ch...@force-elite.com> wrote:
> I counted two votes about 2.1.7-beta:
> +1: Brad, Joe
>
> No one else put votes in the thread.
+1, with a strong concern that the non-showstopper issues are highlighted