You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jim Jagielski <ji...@jaguNET.com> on 2007/08/06 19:28:23 UTC
Re: svn commit: r563196 - /httpd/httpd/branches/2.2.x/STATUS
Ummm... These didn't have 3 +1 votes.
So why were they applied and committed??
fuankg@apache.org wrote:
>
> Author: fuankg
> Date: Mon Aug 6 10:11:20 2007
> New Revision: 563196
>
> URL: http://svn.apache.org/viewvc?view=rev&rev=563196
> Log:
> removed applied backports.
>
> Modified:
> httpd/httpd/branches/2.2.x/STATUS
>
> Modified: httpd/httpd/branches/2.2.x/STATUS
> URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.2.x/STATUS?view=diff&rev=563196&r1=563195&r2=563196
> ==============================================================================
> --- httpd/httpd/branches/2.2.x/STATUS (original)
> +++ httpd/httpd/branches/2.2.x/STATUS Mon Aug 6 10:11:20 2007
> @@ -187,17 +187,6 @@
> http://people.apache.org/~chrisd/patches/mod_dbd_pools_groups/mpm_child_init-beos-2.2.x.patch
> +0: chrisd (abstaining; unable to test)
>
> - * netware MPM: Destroy pmain pool when exiting ap_mpm_run() so that
> - cleanups registered in modules' child_init hooks are performed (e.g.,
> - mod_log_config and mod_dbd).
> - Trunk version of patch:
> - http://svn.apache.org/viewvc?view=rev&revision=491907
> - 2.2.x version of patch:
> - http://people.apache.org/~chrisd/patches/mod_dbd_pools_groups/mpm_child_init-netware-2.2.x.patch
> - +0: chrisd (abstaining; unable to test)
> - +1: bnicholes - I don't know of any problems that this specifically addresses, but it seems like
> - the right thing to do.
> -
> * mod_dbd: Create memory sub-pools for each DB connection and close
> DB connections in a pool cleanup function. Ensure prepared statements
> are destroyed before DB connection is closed. When using reslists,
> @@ -246,11 +235,6 @@
> apr_brigade_cleanup inside of ap_proxygetline then. Furthermore the
> check for a buffer overflow a few lines later is not correct any more
> (now an error (APR_ENOSPC) is returned instead).
> -
> - * netware build system:
> - removed obsolete stuff
> - http://svn.apache.org/viewvc?view=rev&revision=521264
> - +1: fuankg, bnicholes
>
> * mod_proxy_ajp: Add support of ProxyIOBufferSize.
> Trunk version of patch:
>
>
--
===========================================================================
Jim Jagielski [|] jim@jaguNET.com [|] http://www.jaguNET.com/
"If you can dodge a wrench, you can dodge a ball."
Re: svn commit: r563196 - /httpd/httpd/branches/2.2.x/STATUS
Posted by Brad Nicholes <BN...@novell.com>.
>>> On 8/6/2007 at 12:28 PM, in message
<5c...@mail.gmail.com>, "Justin
Erenkrantz" <ju...@erenkrantz.com> wrote:
> On 8/6/07, Jim Jagielski <ji...@jagunet.com> wrote:
>> Ummm... These didn't have 3 +1 votes.
>>
>> So why were they applied and committed??
>
> I think for platform-specific code we've been okay with a smaller
> consensus than 3.
>
> If our only two NetWare guys agree on the change, then I doubt the
> rest of us have anything to add to the conversation. And until
> recently, we only had one NetWare-savvy committer; so we're making
> progress towards getting 3. =P -- justin
Not to stir the pot or anything, just to add some context, until recently when we gave faunkg commit rights on the httpd and apr projects, I was the only NetWare maintainer. As such, you never really saw any NetWare backports hit the status file because I just commited them. Yes, the patches flowed through trunk first, but nobody really noticed because nobody really cared, other than me. If I had proposed the backports, I would have never achieved 3 +1's on anything. Now that we have another NetWare person, I feel that NetWare backports should be seen in the status file and voted on within a reasonable time period (lazy concensus, so to speak). This is what I instructed faunkg to do with the NetWare patches that he wanted to backport to 2.2. But even in this situation there are now only two of us, so at best a NetWare backport will only get 2 +1's and with my time for doing reviews or anything else related to Apache, becoming more limited, even that is stretching it. I think that there are sometimes when lazy consensus needs to override strict RTC. NetWare is one of them. So for now like Justin said, at least 2 +1's is better than nothing. :)
Just my thinking,
Brad
Re: svn commit: r563196 - /httpd/httpd/branches/2.2.x/STATUS
Posted by Jim Jagielski <ji...@jagunet.com>.
On Aug 6, 2007, at 2:28 PM, Justin Erenkrantz wrote:
> On 8/6/07, Jim Jagielski <ji...@jagunet.com> wrote:
>> Ummm... These didn't have 3 +1 votes.
>>
>> So why were they applied and committed??
>
> I think for platform-specific code we've been okay with a smaller
> consensus than 3.
>
true enough, but since we are doing that, the svn logs should
show that clearly, simply for historical purposes.
Re: svn commit: r563196 - /httpd/httpd/branches/2.2.x/STATUS
Posted by Jim Jagielski <ji...@jagunet.com>.
On Aug 6, 2007, at 2:28 PM, Justin Erenkrantz wrote:
> On 8/6/07, Jim Jagielski <ji...@jagunet.com> wrote:
>> Ummm... These didn't have 3 +1 votes.
>>
>> So why were they applied and committed??
>
> I think for platform-specific code we've been okay with a smaller
> consensus than 3.
>
true enough, but since we are doing that, the svn logs should
show that clearly, simply for historical purposes.
Re: svn commit: r563196 - /httpd/httpd/branches/2.2.x/STATUS
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 8/6/07, Jim Jagielski <ji...@jagunet.com> wrote:
> Ummm... These didn't have 3 +1 votes.
>
> So why were they applied and committed??
I think for platform-specific code we've been okay with a smaller
consensus than 3.
If our only two NetWare guys agree on the change, then I doubt the
rest of us have anything to add to the conversation. And until
recently, we only had one NetWare-savvy committer; so we're making
progress towards getting 3. =P -- justin
Re: svn commit: r563196 - /httpd/httpd/branches/2.2.x/STATUS
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 8/6/07, Jim Jagielski <ji...@jagunet.com> wrote:
> Ummm... These didn't have 3 +1 votes.
>
> So why were they applied and committed??
I think for platform-specific code we've been okay with a smaller
consensus than 3.
If our only two NetWare guys agree on the change, then I doubt the
rest of us have anything to add to the conversation. And until
recently, we only had one NetWare-savvy committer; so we're making
progress towards getting 3. =P -- justin