> I think that's overly cautious given the simplicity of the problem and the  
> fix, but it's your call.
> But even as a matter of principle, I don't know why you'd need a new RC in  
> one case, but not in the other. You'd have a release different from the  

Because revert means going back to old code, in which the problems are
already known and which was tested, so while we don't get the fix for
this bug, we can be reasonably sure there will be no new bugs introduced
by the revert. Since we have a sad history of last-minute commits, I
prefer to take the less risky pass.

> last RC in both cases. It's true that the revert would only restore old  
> code, but, in general, you can't be sure the old code is still correct in  
> the context of the other changes since the last release (i.e. something  
> else could rely on the change. In principle).

In principle, yes. But I have three options here: old code, new code and
leave it as is. Of those three, old code with high probability does not
make things any worse (it is quite improbable that we have some other
change relying on the difference between old and new code - if there is,
we'd have to revert that too, of course), new code is unknown, and
leaving it as is means having known crash bug - which is worse than
original bug that manifests itself only in some limited circumstances
and does not lead to crash. I think the best way to go in this
particular case is revert and have it in the next release. We're doing
them each 4-6 weeks now so it's a small price to pay for more stable
code I think.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

PHP CVS Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to