You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jeff Trawick <tr...@attglobal.net> on 2003/02/26 13:31:12 UTC
Re: cvs commit: httpd-2.0 CHANGES
stas@apache.org wrote:
> stas 2003/02/25 15:33:55
>
> Modified: server Tag: APACHE_2_0_BRANCH connection.c
> . Tag: APACHE_2_0_BRANCH CHANGES
> Log:
> check the return value of ap_run_pre_connection(). So if the
> pre_connection phase fails (without setting c->aborted)
> ap_run_process_connection is not executed.
> Reviewed by: trawick, jim
I don't recall a vote for merging it into the stable branch.
Re: cvs commit: httpd-2.0 CHANGES
Posted by Jeff Trawick <tr...@attglobal.net>.
Greg Stein wrote:
> On Wed, Feb 26, 2003 at 05:10:12PM -0800, Justin Erenkrantz wrote:
>
> >--On Thursday, February 27, 2003 12:02 PM +1100 Stas Bekman
> > wrote:
> >
> >
> >>So if absolutely anything added to the dev branch must have a vote
> >>for before merging back to the stable branch, I stand corrected and
> >>will make sure that this won't happen again in the future. I
> >>thought that the common sense should be applied when judging what
> >>can be backported without the vote.
> >
> >Heh. The entire reason for the vote is to prevent 'common sense'
> >from interfering with the stability of the tree. -- justin
>
>
> Bah. That's insanity. A bug fix is a bug fix. We never took votes for bug
> fixes for 1.3, and I see no reason to start now.
Please go update STATUS with your vote on how this should be handled
(the R-T-C vs. C-T-R vote). I think some folks may not be happy with
the current philosophy but haven't made their feelings known formally.
If you aren't happy with the current choices, add one.
Re: cvs commit: httpd-2.0 CHANGES
Posted by Jeff Trawick <tr...@attglobal.net>.
Greg Ames wrote:
> Aaron Bannert wrote:
>
> > I see the need for letting patches age in the unstable tree, but
> > I think we could do that without having to vote on each and
> > every change.
>
>
> Yeah, that's what I meant by "lazy consensus" in the STATUS file.
I would think lazy consensus would be when somebody actually states that
they want to merge something and nobody stands up and says "no" within a
certain timeframe.
Somehow the word "consensus" doesn't seem appropriate when there is no
shared knowledge about what might get merged but instead it just gets
suddenly merged.
> But I can also see problems with that being the policy. What's mainline
> code vs. non-mainline?
not impossible to describe, if you aren't too picky
if it gets exercised by GET /cgi-bin/printenv or by GET /manual/ using
the default config it is mainline? just a guess
Re: cvs commit: httpd-2.0 CHANGES
Posted by Greg Ames <gr...@apache.org>.
Aaron Bannert wrote:
>
> On Thursday, February 27, 2003, at 07:56 AM, Greg Ames wrote:
>
>> Most of us have committed bug fixes with the best of intentions which
>> were not quite complete or had unintended side effects. I certainly
>> have - the deferred write pool stuff in core_output_filter comes to
>> mind. Letting the fixes age a bit in the unstable tree reduces the
>> probability of unpleasant surprises happening in the stable tree, at
>> least for mainline code. We can be extra diligent about
>> reviewing/testing changes that we know are not mainline.
>
>
> I see the need for letting patches age in the unstable tree, but
> I think we could do that without having to vote on each and
> every change.
Yeah, that's what I meant by "lazy consensus" in the STATUS file.
But I can also see problems with that being the policy. What's mainline code
vs. non-mainline? How long is long enough? The answer could change around
Hannukkah/Christmas/New Year's LinuxWorld/ApacheCon/whatever.
Greg
Re: cvs commit: httpd-2.0 CHANGES
Posted by Aaron Bannert <aa...@clove.org>.
On Thursday, February 27, 2003, at 07:56 AM, Greg Ames wrote:
> Most of us have committed bug fixes with the best of intentions which
> were not quite complete or had unintended side effects. I certainly
> have - the deferred write pool stuff in core_output_filter comes to
> mind. Letting the fixes age a bit in the unstable tree reduces the
> probability of unpleasant surprises happening in the stable tree, at
> least for mainline code. We can be extra diligent about
> reviewing/testing changes that we know are not mainline.
I see the need for letting patches age in the unstable tree, but
I think we could do that without having to vote on each and
every change.
-aaron
Re: cvs commit: httpd-2.0 CHANGES
Posted by Jeff Trawick <tr...@attglobal.net>.
Greg Ames wrote:
>
> mind. Letting the fixes age a bit in the unstable tree reduces the
> probability of unpleasant surprises happening in the stable tree, at
> least for mainline code. We can be extra diligent about
> reviewing/testing changes that we know are not mainline.
Note that for me and perhaps others, the philosophy you just mentioned
is not something I would vote for under any forseeable circumstances.
Re: cvs commit: httpd-2.0 CHANGES
Posted by Greg Ames <gr...@apache.org>.
Justin Erenkrantz wrote:
> --On Wednesday, February 26, 2003 7:55 PM -0800 Greg Stein
> <gs...@lyra.org> wrote:
>
>> And remember: this *is* source control. If somebody commits a bug
>> fix and people want to shoot it down, then we can revert it. But
>> assuming correctness and committing the fix is hella better than
>> gating every single little change.
>
>
> We have lazy consensus on the unstable tree (2.1). I agree with you
> 100% in the context of httpd-2.1 - go commit first - break the tree - we
> can revert changes easily as we have no expectations of stability there.
>
> But, I don't trust anyone's 'common sense' to know whether the most
> trivial fix broke anything or whether a bug fix is 'right.' Yes, it
> means gating changes on stable (2.0), but that's a price I'm willing to
> see us pay. I'd hope our code quality and stability improves because of
> that. -- justin
Well said, Justin.
Most of us have committed bug fixes with the best of intentions which were not
quite complete or had unintended side effects. I certainly have - the deferred
write pool stuff in core_output_filter comes to mind. Letting the fixes age a
bit in the unstable tree reduces the probability of unpleasant surprises
happening in the stable tree, at least for mainline code. We can be extra
diligent about reviewing/testing changes that we know are not mainline.
Greg
Re: cvs commit: httpd-2.0 CHANGES
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Wednesday, February 26, 2003 7:55 PM -0800 Greg Stein
<gs...@lyra.org> wrote:
> And remember: this *is* source control. If somebody commits a bug
> fix and people want to shoot it down, then we can revert it. But
> assuming correctness and committing the fix is hella better than
> gating every single little change.
We have lazy consensus on the unstable tree (2.1). I agree with you
100% in the context of httpd-2.1 - go commit first - break the tree -
we can revert changes easily as we have no expectations of stability
there.
But, I don't trust anyone's 'common sense' to know whether the most
trivial fix broke anything or whether a bug fix is 'right.' Yes, it
means gating changes on stable (2.0), but that's a price I'm willing
to see us pay. I'd hope our code quality and stability improves
because of that. -- justin
Re: cvs commit: httpd-2.0 CHANGES
Posted by Bill Stoddard <bi...@wstoddard.com>.
Greg Stein wrote:
> On Wed, Feb 26, 2003 at 05:10:12PM -0800, Justin Erenkrantz wrote:
>
>>--On Thursday, February 27, 2003 12:02 PM +1100 Stas Bekman
>><st...@stason.org> wrote:
>>
>>
>>>So if absolutely anything added to the dev branch must have a vote
>>>for before merging back to the stable branch, I stand corrected and
>>>will make sure that this won't happen again in the future. I
>>>thought that the common sense should be applied when judging what
>>>can be backported without the vote.
>>
>>Heh. The entire reason for the vote is to prevent 'common sense'
>>from interfering with the stability of the tree. -- justin
>
>
> Bah. That's insanity. A bug fix is a bug fix. We never took votes for bug
> fixes for 1.3, and I see no reason to start now.
>
> Feature changes? Sure, we voted for those.
>
>
> Seriously, people. If there is a bug, then it should be fixed no matter
> where it lies. Sure, there can be some waffling based on *how* a bug is
> fixed, and hopefully people will know when to ask.
>
> What's the problem with fixing a bug. Really?
We've had problems in the past with folks rewriting major portions of
the server to fix relatively insignificant bugs and breaking major
function across several releases as a result. The rewrites were
generally NOT posted as a patch on the dev list prior to being committed
and that is the real problem (ie, I can deal with a patch that is not
quite right the first go'round provided folks were give an opportunity
to review it before it goes in).
Once code is committed, it is a difficult to get it out without bruising
egos and causing waves of bad mojo. Been there, done that and threw
away the snow globe.
I am not going to cite examples so don't ask because it's not productive
to go digging in the past.
Bill
Re: cvs commit: httpd-2.0 CHANGES
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Feb 26, 2003 at 05:10:12PM -0800, Justin Erenkrantz wrote:
> --On Thursday, February 27, 2003 12:02 PM +1100 Stas Bekman
> <st...@stason.org> wrote:
>
> > So if absolutely anything added to the dev branch must have a vote
> > for before merging back to the stable branch, I stand corrected and
> > will make sure that this won't happen again in the future. I
> > thought that the common sense should be applied when judging what
> > can be backported without the vote.
>
> Heh. The entire reason for the vote is to prevent 'common sense'
> from interfering with the stability of the tree. -- justin
Bah. That's insanity. A bug fix is a bug fix. We never took votes for bug
fixes for 1.3, and I see no reason to start now.
Feature changes? Sure, we voted for those.
Seriously, people. If there is a bug, then it should be fixed no matter
where it lies. Sure, there can be some waffling based on *how* a bug is
fixed, and hopefully people will know when to ask.
What's the problem with fixing a bug. Really?
And remember: this *is* source control. If somebody commits a bug fix and
people want to shoot it down, then we can revert it. But assuming
correctness and committing the fix is hella better than gating every single
little change.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: cvs commit: httpd-2.0 CHANGES
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Thursday, February 27, 2003 12:02 PM +1100 Stas Bekman
<st...@stason.org> wrote:
> So if absolutely anything added to the dev branch must have a vote
> for before merging back to the stable branch, I stand corrected and
> will make sure that this won't happen again in the future. I
> thought that the common sense should be applied when judging what
> can be backported without the vote.
Heh. The entire reason for the vote is to prevent 'common sense'
from interfering with the stability of the tree. -- justin
Re: cvs commit: httpd-2.0 CHANGES
Posted by Stas Bekman <st...@stason.org>.
Jeff Trawick wrote:
> stas@apache.org wrote:
>
>> stas 2003/02/25 15:33:55
>>
>> Modified: server Tag: APACHE_2_0_BRANCH connection.c
>> . Tag: APACHE_2_0_BRANCH CHANGES
>> Log:
>> check the return value of ap_run_pre_connection(). So if the
>> pre_connection phase fails (without setting c->aborted)
>> ap_run_process_connection is not executed.
>> Reviewed by: trawick, jim
>
> I don't recall a vote for merging it into the stable branch.
I figured, since it's a segfault bug fix (httpd was segfaulting when
run_process_connection was run, when pre_connection has failed) it's an
obvious 'must go into the stable branch' (making it more stable). My patch
hasn't introduced a new API or broken anything, other than doing something
that should have been done in first place: checking the return value of the call.
So if absolutely anything added to the dev branch must have a vote for before
merging back to the stable branch, I stand corrected and will make sure that
this won't happen again in the future. I thought that the common sense should
be applied when judging what can be backported without the vote.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com