Re: /httpd/httpd/branches/2.2.x/STATUS

[Nick Kew <ni...@webthing.com>]

On Mon, 29 Oct 2007 20:56:26 -0000
jim@apache.org wrote:

> httpd/httpd/branches/2.2.x/STATUS Mon Oct 29 13:56:25 2007 @@ -226,6
> +226,17 @@ niq: Doesn't allocating 2^n+1 bytes risk being horribly
> inefficient? Would it make sense to reduce AP_IOBUFSIZE to 8091 so
> buf doesn't go one over a big boundary?
> +     jim: The issue is that [chop]

Jim, that's not what I was asking.  But anyway, given that the "big"
boundary is 8192 not 8092, my question is moot.

Today have another discussion that would be better aired on-list
than in STATUS: PR42592 and PR41798:

  * The first is small and simple, but went through a couple of
    iterations.  AIUI you're now objecting based on a comment
    that was right for r583002, partially invalidated but not
    updated in r583803, but only properly fixed in r588791.
    That seems to me a tenuous reason for a veto, given that
    there is also a proposal to backport r588791.

  * The second is more complex.  Because of the order of changes
    to trunk, it needs the first as prerequisite.  To make a separate
    change for it would necessarily invalidate the other patch.

There are far too many interlinked combinations here to deal with
individually.  So if the veto stands, I think I'll just have to
replace both proposals with a combined patch for both bugs.
Unless someone has a better idea?

-- 
Nick Kew

Application Development with Apache - the Apache Modules Book
http://www.apachetutor.org/

Re: /httpd/httpd/branches/2.2.x/STATUS

[Jim Jagielski <ji...@jaguNET.com>]

On Oct 29, 2007, at 5:44 PM, Nick Kew wrote:

>
>   * The second is more complex.  Because of the order of changes
>     to trunk, it needs the first as prerequisite.  To make a separate
>     change for it would necessarily invalidate the other patch.
>
> There are far too many interlinked combinations here to deal with
> individually.  So if the veto stands, I think I'll just have to
> replace both proposals with a combined patch for both bugs.
> Unless someone has a better idea?
>

I think that a combined patch that addresses both "bugs" makes the
most sense... I can't see approving one and not the other, due
to the effects on existing users :)