--On Wednesday, February 26, 2003 7:55 PM -0800 Greg Stein <[EMAIL PROTECTED]> 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
