[Fwd: [PATCH] Backport of HEADs output API]

I strongly disagree, for two reasons:

1. We are going to release an alpha3, that's the perfect time for such change
2. The OB code is messy right now, Mike's work cleaned it up and makes
   it more maintainable. 5.3 is going to be here for a long time, let
   make our work easier.

I've just been reading the thread as it's gone along and not

contributing, but I'd like to add that I'm +1 with Pierre here.

--
</Daniel P. Brown>
More full-root dedicated server packages:
Intel 2.4GHz/60GB/512MB/2TB $49.99/mo.
Intel 3.06GHz/80GB/1GB/2TB $59.99/mo.
Intel 2.4GHz/320/GB/1GB/3TB $74.99/mo.
Dedicated servers, VPS, and hosting from $2.50/mo.

On Fri, Sep 26, 2008 at 9:38 PM, Lukas Kahwe Smith
mls@pooteeweet.org wrote:

So unless you can take our worries away in terms of BC issues, I
guess we
would prefer to leave this patch out of PHP 5.3.

I strongly disagree, for two reasons:

1. We are going to release an alpha3, that's the perfect time for
   such change

Perfect might be overstating things. Lets say it makes it possible to
even consider it.

2. The OB code is messy right now, Mike's work cleaned it up and makes
   it more maintainable. 5.3 is going to be here for a long time, let
   make our work easier.

Well but messy just means its even harder to ensure BC. Like I said in
my mail, we would have loved to have seen this earlier (when Johannes
originally asked for this). The fact that nobody stepped up back then
is also telling us RM's that there is a definitive risk that if there
are issues, we might end up with a similar situation as back then.
Without having evaluated the code in the last detail, it seems that OB
stuff is not small or self contained by any stretch of the definition.
Given that this patch fixes no existing bugs, we have decided that its
too risky to do right before what we hope will be the final alpha3 in
one of the most feature rich minor releases in PHP history. We do not
want to risk delay this release for something that might be messy, but
has/does work more or less reliably for people.

regards,
Lukas Kahwe Smith
mls@pooteeweet.org

Lukas Kahwe Smith wrote:

Lukas Kahwe Smith wrote:

well the question is does it fix some real world bugs? this late
in the
game i would not want to include these changes if they "just" add
features ..

Huh? :) The question to me is, why did you ask me to do it, when
you're not sure what it's about? Not to be anally at all... ;)
I guess we cleared up the misunderstanding on IRC.
The greatest plus to me are:

• getting rid of monolithic php_end_ob_buffer()
• getting rid of output handler specific code in SAPI.c
• being able to hook from the running output handler to change
  it's behavior
• being able to clearly configure conflicts and reverse
  conflicts between output handlers
  These are all convincing arguments to have done this earlier. But
  Johannes and I are a bit worried, that this code did not see that
  much testing since it was checked in to HEAD quite a while ago. And
  seeing that the backport is mainly cleanup and not bug fixing, we
  are a bit worried about the risk this backport has (not necessarily
  in it introducing bugs, but more about BC issues here and there).
  Especially since it seems that you are the only one who actively
  looks after output buffering .. (Johannes actually asked to have
  this stuff in PHP 5.3 months ago, but you were a bit MIA back
  then .. and nobody else showed interest).
  So unless you can take our worries away in terms of BC issues, I
  guess we would prefer to leave this patch out of PHP 5.3.
  Sorry about the misunderstanding and the work you put into
  producing this patch.

The patch fixes several output buffer bugs. Those alone are enough
to allow this getting in PHP_5_3 and really get TESTED too.

if it does fix bugs .. that changes things of course .. but i asked
Mike specifically about this .. and he did not mention this .. so does
it fix bugs or not?

regards,
Lukas Kahwe Smith
mls@pooteeweet.org

On Fri, Sep 26, 2008 at 21:38, Lukas Kahwe Smith
mls@pooteeweet.org wrote:

and I are a bit worried, that this code did not see that much
testing since
it was checked in to HEAD quite a while ago. And seeing that the
backport is

That sentence worries me a bit. Are you advocating developing new
features in 5.x branches rather then HEAD?

Not at all. I am not sure how you even read that into what I said.

That code has been in HEAD for months, I so no reason not to merge it.
We are in alpha phase for a reason just like this.

All I said was that the fact that it has been in HEAD is no proof that
there are no BC issues or even new bugs in it. Again Johannes asked
for this to be merged long long long ago and nobody reacted. Now we
are at alpha2, hoping to release the last alpha soon. We have plenty
of other big stuff that really wants to make it out of the door.

BTW: we have a similar situation for mcrypt. We have
"cleanups" (though Derick does not define them as such) in HEAD, which
have not been merged to 5.3. I dont like this at all, since either
cleanups make sense or they dont. However the larger the cleanups, the
messier the old code, the trickier it is to get BC just right and the
less I think it makes sense to add such cleanups now.

regards,
Lukas Kahwe Smith
mls@pooteeweet.org