On Jul 8, 2015 6:59 AM, "Yann Ylavic" wrote:
>
> However maybe the proposed backport about mod_reqtimeout (PR 56729) is
> worth being included too, but that's not a showstopper.
> It somehow made his way through 2.2.30 already (r1678698) but for
> 2.4.x this partial fix isn't enough (due to EOR ha
On Wed, Jul 8, 2015 at 2:16 AM, William A Rowe Jr wrote:
> 2.4 still needs one reviewer to make the decision so we can have a 2.4, at
> last.
I voted the revert, applied accepted backports, and updated tests
framework accordingly.
I guess both 2.4.16 and 2.2.30 could be T&R now.
However maybe th
2.4 still needs one reviewer to make the decision so we can have a 2.4, at
last.
Thanks to Mike for the review on the 2.2 showstopper, jumping ahead on
tarballs for 2.2.30 in the morning.
On Mon, Jul 6, 2015 at 10:38 AM, William A Rowe Jr
wrote:
> Hope everyone enjoyed a nice weekend, and a goo
Hope everyone enjoyed a nice weekend, and a good holiday for those here in
the States!
On 2.4, one significant issue remains unsettled...
*) mod_alias: Limit Redirect expressions to directory (Location) context
and redirect statuses (implicit or explicit).
trunk patch: http://svn.apac
On Fre 14.04.2006 15:12, William A. Rowe, Jr. wrote:
... that would prevent me from rolling early tomorrow? Please raise
hands now, and lets see if we can't get them committed. I'm thinking
of patches-to-apply, not new efforts :) There's always 2.0.57 for new
and exciting bug fixes.
Is this
Ruediger Pluem wrote:
On 04/15/2006 12:12 AM, William A. Rowe, Jr. wrote:
... that would prevent me from rolling early tomorrow? Please raise
hands now, and lets see if we can't get them committed. I'm thinking
of patches-to-apply, not new efforts :) There's always 2.0.57 for
new and exciti
On 04/15/2006 12:12 AM, William A. Rowe, Jr. wrote:
> ... that would prevent me from rolling early tomorrow? Please raise
> hands now, and lets see if we can't get them committed. I'm thinking
> of patches-to-apply, not new efforts :) There's always 2.0.57 for
> new and exciting bug fixes.
No
... that would prevent me from rolling early tomorrow? Please raise
hands now, and lets see if we can't get them committed. I'm thinking
of patches-to-apply, not new efforts :) There's always 2.0.57 for
new and exciting bug fixes.
Bill
Hi,
I finally got the time to compile 2.0.43; the problem is solved !
Thanks to all those who searched an found memory leaks !!
Peter.
Peter Van Biesen wrote:
>There was still a memory leak when downloading large files, but only
>when proxy chaining. I haven't tested the latest release yet as
Jeff Trawick <[EMAIL PROTECTED]> writes:
> 3) a cool problem you'll run into after fixing the above
>
> download a binary build
> install it
> run apxs
> ouch!
>
> apxs doesn't pick up the environment variable needed to find libapr,
> libaprutil, libexpat, so "httpd -l" bombs...
This doesn't s
Jeff Trawick <[EMAIL PROTECTED]> writes:
> 1) $prefix isn't getting fixed-up by install-bindist.sh, at least on
>Solaris
now fixed
> 2) where is the build directory? we need some stuff like
>config_vars.mk
now fixed
--
Jeff Trawick | [EMAIL PROTECTED]
Born in Roswell... married an al
"Bill Stoddard" <[EMAIL PROTECTED]> writes:
> How 'bout creating a script in bin, setupenvars.bat than folks need to learn to run
>before
> issuing httpd -yadda? Not pretty but very straight forward...
we already have something called envvars which can be used, but that
pollutes the current en
Bill
- Original Message -
From: "Jeff Trawick" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, April 26, 2002 10:55 AM
Subject: more fun with binary builds (showstoppers?)
> 1) $prefix isn't getting fixed-up by install-bindist.sh, at least on
>Solaris
&
1) $prefix isn't getting fixed-up by install-bindist.sh, at least on
Solaris
2) where is the build directory? we need some stuff like
config_vars.mk
3) a cool problem you'll run into after fixing the above
download a binary build
install it
run apxs
ouch!
apxs doesn't pick up the environ
Paul J. Reder wrote:
> Cliff,
>
> I know you are busy, is there something I can do to help with this
> since the pools stuff is in now? Does it still just need to have
> the malloc replaced and the code tested?
>
> I'm happy to help in any way possible.
Me too. Cliff, what's your recommendati
Cliff,
I know you are busy, is there something I can do to help with this
since the pools stuff is in now? Does it still just need to have
the malloc replaced and the code tested?
I'm happy to help in any way possible.
Cliff Woolley wrote:
> On Tue, 12 Mar 2002, Jeff Trawick wrote:
>
>
>>2)
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Jeff Trawick
> Sent: 13 March 2002 00:00
> Cliff Woolley <[EMAIL PROTECTED]> writes:
>
>> The pool allocator change is done AFAIK -- Sander, are there any other
>> changes that need to be made above the ones in the patch you sent
Cliff Woolley <[EMAIL PROTECTED]> writes:
> The pool allocator change is done AFAIK -- Sander, are there any other
> changes that need to be made above the ones in the patch you sent me? If
> not, please go ahead and commit.
>
> The bucket freelist change was kind of waiting on the pool allocat
On Tue, 12 Mar 2002, Jeff Trawick wrote:
> 2) * API changes planned for 2.0 that should happen before the
> GA release:
> * Free lists for bucket allocation
> * Pool allocator change
>
> Can anybody comment on the current status of either of these?
The pool allocat
1) * If any request gets to the core handler, without a flag that this
r->filename was tested by dir/file_walk, we need to 500 at the very
end of the ap_process_request_internal() processing. This provides
authors of older modules better compatibility, while still improving
I entirely agree with Bill and Roy here.
The release manager owns the release short of using the big stick of a
full fledged vote. It's a miserable job; bow down in sympathy.
I have never worked on any project where that wasn't the case. But
every project I've worked on people would grab one
k' the project. While
vetos sometimes appear that way, a specific veto of a specific change or patch
does no such thing.
> > We are [now] treating showstoppers in 2.0 as sancrosect. That
> > means they can be overridden.
>
> If they're sacrosanct, then they can&#
"issue". Having misunderstood and not well defined
terms like this is the reason we keep having discussions about release
procedures, voting, and showstoppers. Why don't we define these terms
once and for all and then work toward some guidelines so we're all on
the same page. Here
* On 2002-02-06 at 16:48,
Jim Jagielski <[EMAIL PROTECTED]> excited the electrons to say:
>
> People should go over the old STATUS files... they were back then
> incredibly useful, but now they are bloated and confusing.
I've felt this way ever since shortly after they became
group-maintained
There has never been a formal position on what a SHOWSTOPPER is. The
earliest uses were things that "either should be fixed or we decide
aren't a problem anymore". That's my current understanding of it as
well. The RM has "final" authority... he can say "I don't want to
release until we have these
* On 2002-02-06 at 16:38,
Roy T. Fielding <[EMAIL PROTECTED]> excited the electrons to say:
>
> A showstopper is just an issue! Damnit guys, if you can't figure this out
> I am going to remove the whole category from STATUS as being obviously bad
> for your brain cells.
Then someone else will
> I add a showstopper to STATUS. One other person says "-1, that's
> not a showstopper". By my interpretation of the rules, they CANNOT
> demote it from showstopper until there are enough people who would
> vote to release (more +1s than -1s). This means that in order to
> demote it, there would h
* On 2002-02-06 at 16:15,
Roy T. Fielding <[EMAIL PROTECTED]> excited the electrons to say:
>
> Nobody can veto a release, period. It is therefore impossible for
> anything to be a showstopper unless it is a pending veto of a commit
> or the group makes a decision by majority of -1 on any rele
From: "William A. Rowe, Jr." <[EMAIL PROTECTED]>
Sent: Wednesday, February 06, 2002 3:02 PM
> From: "Rodent of Unusual Size" <[EMAIL PROTECTED]>
> Sent: Wednesday, February 06, 2002 2:53 PM
>
> > I think that's bogus, too. If someone thinks something is serious
> > enough to stop a release, th
On Wed, Feb 06, 2002 at 03:33:04PM -0500, Rodent of Unusual Size wrote:
> "Roy T. Fielding" wrote:
> >
> > A showstopper, aside from a yet-to-be-reverted veto, can be
> > moved from one section of STATUS to another by the RM (or
> > anyone, for that matter) whenever they want. It is only
> > a s
Nobody can veto a release, period. It is therefore impossible for
anything to be a showstopper unless it is a pending veto of a commit
or the group makes a decision by majority of -1 on any release until
the problem is fixed. If the RM doesn't think that is the case,
then they should move the is
> We are [now] treating showstoppers in 2.0 as sancrosect. That
> means they can be overridden.
If they're sacrosanct, then they can't be overridden.
> But one individual cannot block the progress of the Apache HTTP
> Project.
Stopping a release from happening is far from
At 03:53 PM 02/06/2002, Rodent of Unusual Size wrote:
>Greg Marr wrote:
> >
> > I read that last sentence as: "An issue becomes a showstopper when
> > it is listed as such in STATUS, and remains one until someone
> vetoes
> > it, at which time it is no longer a showstopper. ..."
>
>I think that's
On Wed, Feb 06, 2002 at 03:53:09PM -0500, Rodent of Unusual Size wrote:
> Greg Marr wrote:
> >
> > I read that last sentence as: "An issue becomes a showstopper when
> > it is listed as such in STATUS, and remains one until someone vetoes
> > it, at which time it is no longer a showstopper. ..."
ble
> to veto a showstopper completely ludicrous. :-)
WRONG. You are proposing that one individual may block a release. That
is diametrically opposed to the spirit of HTTP. We are [now] treating
showstoppers in 2.0 as sancrosect. That means they can be overridden.
It does not mean they may be remo
* On 2002-02-06 at 15:54,
Justin Erenkrantz <[EMAIL PROTECTED]> excited the electrons to say:
>
> I think there is a higher barrier of entry to have an item listed
> as a showstopper. If people can not reproduce a problem listed as
> a showstopper or do not believe it is a showstopper, then th
up with a clarification, then I believe it is
permissible to remove it as a showstopper.
No one is removing things from STATUS. We are just demoting it
from showstopper because the group agrees particular items aren't
showstoppers. If one person felt so strongly about an issue that
no one el
Greg Marr wrote:
>
> I read that last sentence as: "An issue becomes a showstopper when
> it is listed as such in STATUS, and remains one until someone vetoes
> it, at which time it is no longer a showstopper. ..."
I think that's bogus, too. If someone thinks something is serious
enough to stop
whenever they want. It is only
> > a showstopper if we ALL agree it is. The category only exists
> > to simply remind us of what needs to be fixed.
>
> Not codified, and certainly not clear:
>
> > Showstoppers
> > Showstoppers are issues that require a fix be
. It is only
> > a showstopper if we ALL agree it is. The category only exists
> > to simply remind us of what needs to be fixed.
>
>Not codified, and certainly not clear:
>
> > Showstoppers
> > Showstoppers are issues that require a fix be in place
> > befor
> to simply remind us of what needs to be fixed.
Not codified, and certainly not clear:
> Showstoppers
> Showstoppers are issues that require a fix be in place
> before the next public release. They are listed in the STATUS
> file in order to focus special attentio
A showstopper, aside from a yet-to-be-reverted veto, can be moved from
one section of STATUS to another by the RM (or anyone, for that matter)
whenever they want. It is only a showstopper if we ALL agree it is.
The category only exists to simply remind us of what needs to be fixed.
Roy
topper (which blocks a release) is essentially
the equivalent of a veto on the release. It's a stoppage
based on a technical issue.
If that's an appropriate way to view it, then we need to
treat showstoppers a little differently:
o whomever identifies a showstopper needs to be named nex
43 matches
Mail list logo
