5.0.5, BC break, fatal error

19 years ago by Pierre Joye — view source

unread

Hello,

Without arguing again about the """fix""" for the memory corruption
discovered earlier this summer and without anyone able to reproduce
with a medium size script, why in the world one applies this fix to
the 5.0 branche?

5.0.5 was supposed to be a security fix release only. I do know many
people who will upgrade and they do have tousands of lines of codes
wrote by many people. Do you really think the answers given in the
various bug reports (http://bugs.php.net/bug.php?id=34468) is good?

And please, do not tell me to come with a patch to fix this problem,
the fix should have not been applied to 5.0.5, period.

Any chance to roll it again without the fix? The fix is not listed in
the NEWS neither in the Changelog.

I know that the chance to get that fixed is null, but I would like to
hear some valid explanations besides the common arrogant answers.

Regards,

--Pierre

19 years ago by Zeev Suraski — view source

unread

At 01:54 12/09/2005, Pierre Joye wrote:

Hello,

Without arguing again about the """fix""" for the memory corruption
discovered earlier this summer and without anyone able to reproduce
with a medium size script, why in the world one applies this fix to
the 5.0 branche?

5.0.5 was supposed to be a security fix release only. I do know many
people who will upgrade and they do have tousands of lines of codes
wrote by many people. Do you really think the answers given in the
various bug reports (http://bugs.php.net/bug.php?id=34468) is good?

And please, do not tell me to come with a patch to fix this problem,
the fix should have not been applied to 5.0.5, period.

Any chance to roll it again without the fix? The fix is not listed in
the NEWS neither in the Changelog.

I know that the chance to get that fixed is null, but I would like to
hear some valid explanations besides the common arrogant answers.

Pierre,

I don't think you're going to get a very good answer here. It boils down
to what you already know - it's a bug which results in corruption, and
that's the only way to fix it. The common decision was that it's more
important to fix this bug than to maintain compatibility, and this even
resulted in a new PHP 'family' (4.4). It's one of those cases where
there's no good solution, only a choice of bad solutions.

Zeev

19 years ago by Pierre Joye — view source

unread

I don't think you're going to get a very good answer here. It boils down
to what you already know - it's a bug which results in corruption, and
that's the only way to fix it. The common decision was that it's more
important to fix this bug than to maintain compatibility, and this even
resulted in a new PHP 'family' (4.4). It's one of those cases where
there's no good solution, only a choice of bad solutions.

4.4.0, correct and I do accept that. but not in 5.0.5. Derick applied
the patch to 5.1 not to 5.0.5. We did agree to apply it there and not
in bug fix releases (and not in security release). Or can you point me
to the common decision? ;)

The bad solution is to do not communicate about that. Reading the
announce of 5.0.5, the only real problem was xml_rpc... If one has
asked to apply the fix to 5.0.5, I'm pretty sure nobody will agree to
add this fatal error.

Regards,

--Pierre

19 years ago by Andi Gutmans — view source

unread

Hey Pierre,

Mini releases are not only for security fixes. We also do bug fixes,
and sometimes even minor functionality (like a new function) which
has very low risk of breaking anything. I don't think 5.0.5 is
different from that.
I do think we could probably be better at communicating these kind of
breakages. Question is wether we should just try harder, or if you
have some other concrete ideas which would be easy to implement and stick to?

Andi

At 07:50 AM 9/12/2005, Pierre Joye wrote:

I don't think you're going to get a very good answer here. It boils down
to what you already know - it's a bug which results in corruption, and
that's the only way to fix it. The common decision was that it's more
important to fix this bug than to maintain compatibility, and this even
resulted in a new PHP 'family' (4.4). It's one of those cases where
there's no good solution, only a choice of bad solutions.

4.4.0, correct and I do accept that. but not in 5.0.5. Derick applied
the patch to 5.1 not to 5.0.5. We did agree to apply it there and not
in bug fix releases (and not in security release). Or can you point me
to the common decision? ;)

The bad solution is to do not communicate about that. Reading the
announce of 5.0.5, the only real problem was xml_rpc... If one has
asked to apply the fix to 5.0.5, I'm pretty sure nobody will agree to
add this fatal error.

Regards,

--Pierre

19 years ago by Pierre Joye — view source

unread

Hi Andi,

Mini releases are not only for security fixes. We also do bug fixes,
and sometimes even minor functionality (like a new function) which
has very low risk of breaking anything. I don't think 5.0.5 is
different from that.

As far as (http://bugs.php.net/bug.php?id=34468) exists and have many
little brothers, I do think 5.0.5 is very different from that.

I do think we could probably be better at communicating these kind of
breakages. Question is wether we should just try harder, or if you
have some other concrete ideas which would be easy to implement and stick to?

The implementation is fine, a bug is fixed (whether I had it or not
does not matter ;). About trying harder, I will say trying, not
bettter, harder, but only trying.

My plan before 4.4.0 and 5.1 releases was about being more carefull.
Not like I did not say anything or tried to convince those "STFU"
people to do so.

The steps:

Do not mix security fixes and BC breaks, this is the worst thing one can do.
Do not move from no warning to a fatal error without an intermediate
version. For example,
5.0.5 will only raise notices, 5.0.6 and up will have the required behaviors.
In any case, it should be wroten in a prominent place both in Changelog and in
the announce text. For example, the 5.0.5 announce only tells that XML_RPC
has a security problem, was it on purpose? bad joke?

4.4.0 for that matter was better than 5.0.5. At least it does not
always die. But the announcements, communications, or any other normal
actions are simply bad, the answers to the bugs report being the
worst.

So yes, I have had better solutions (from a user point of view), but
as you said, it is now too late anyway. But I do not consider that
S'ingTFU will help us to be better :-)

Regards,

--Pierre

19 years ago by Derick Rethans — view source

unread

I don't think you're going to get a very good answer here. It boils down
to what you already know - it's a bug which results in corruption, and
that's the only way to fix it. The common decision was that it's more
important to fix this bug than to maintain compatibility, and this even
resulted in a new PHP 'family' (4.4). It's one of those cases where
there's no good solution, only a choice of bad solutions.

4.4.0, correct and I do accept that. but not in 5.0.5. Derick applied
the patch to 5.1 not to 5.0.5. We did agree to apply it there and not
in bug fix releases (and not in security release). Or can you point me
to the common decision? ;)

I didn't even apply it to 5.1, otherwise it would have been a notice
there too.

Derick

--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org