Hey,
Could one of you write up a short RFC on this patch? Just some details about the bugs fixed, known BC breaks and (undocumented) edge case changes. This would be helpful for anyone wanting to review their code and testing as well as documentation.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
24.3.2010 12:54, Lukas Kahwe Smith wrote:
Hey,
Could one of you write up a short RFC on this patch? Just some details about the bugs fixed, known BC breaks and (undocumented) edge case changes. This would be helpful for anyone wanting to review their code and testing as well as documentation.
ROFLMAO. You can stick your RFCs where sun does not shine. I will not contribute
anything as long as you're acting like some project manager.
--Jani
24.3.2010 12:54, Lukas Kahwe Smith wrote:
Hey,
Could one of you write up a short RFC on this patch? Just some details
about the bugs fixed, known BC breaks and (undocumented) edge case changes.
This would be helpful for anyone wanting to review their code and testing as
well as documentation.ROFLMAO. You can stick your RFCs where sun does not shine. I will not
contribute
anything as long as you're acting like some project manager.--Jani
--
And you did it again...
Tyrael
Hey,
Could one of you write up a short RFC on this patch? Just some details about the bugs fixed, known BC breaks and (undocumented) edge case changes. This would be helpful for anyone wanting to review their code and testing as well as documentation.
I really do not see why this even needs a discussion. Its been in
trunk for years already. People have had plenty of time to give
feedback.
Is there really anyone who doesn't want this committed? For what reason?
-Hannes
Hey,
Could one of you write up a short RFC on this patch? Just some details about the bugs fixed, known BC breaks and (undocumented) edge case changes. This would be helpful for anyone wanting to review their code and testing as well as documentation.
I really do not see why this even needs a discussion. Its been in
trunk for years already. People have had plenty of time to give
feedback.Is there really anyone who doesn't want this committed? For what reason?
This isnt about getting a reason not to commit this. As you can see in the above quoted mail from me, I was asking for this RFC for various other reasons.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
Hey,
Could one of you write up a short RFC on this patch? Just some details about the bugs fixed, known BC breaks and (undocumented) edge case changes. This would be helpful for anyone wanting to review their code and testing as well as documentation.
I really do not see why this even needs a discussion. Its been in
trunk for years already. People have had plenty of time to give
feedback.Is there really anyone who doesn't want this committed? For what reason?
This isnt about getting a reason not to commit this. As you can see in the above quoted mail from me, I was asking for this RFC for various other reasons.
Search the archives. Do your homework.
3 years and 9 months ago the patch was posted to internals for review.
It included README files, TODO list, tests, tests, tests and explanations.
Few weeks later it got committed.
The commit got reviewed by various parties and some enhancements were made.
Every single procedure was followed to the letter.
People were happy.
You cannot seriously be expecting more then that, nearly 4years later?
Some links to get you started:
http://php.markmail.org/message/ujx2htvdzerrxgfe?q=README.NEW-OUTPUT-API+from:%22Michael+Wallner%22+order:date-forward
http://php.markmail.org/message/n22c6ye5boe2rtjk?q=README.NEW-OUTPUT-API+from:%22Michael+Wallner%22+order:date-forward&page=1
http://php.markmail.org/message/jgsd2umnm5lk37b6?q=README.NEW-OUTPUT-API+from:%22Michael+Wallner%22+order:date-forward&page=1
-Hannes
Hey,
Could one of you write up a short RFC on this patch? Just some details about the bugs fixed, known BC breaks and (undocumented) edge case changes. This would be helpful for anyone wanting to review their code and testing as well as documentation.
I really do not see why this even needs a discussion. Its been in
trunk for years already. People have had plenty of time to give
feedback.Is there really anyone who doesn't want this committed? For what reason?
This isnt about getting a reason not to commit this. As you can see in the above quoted mail from me, I was asking for this RFC for various other reasons.
Search the archives. Do your homework.
3 years and 9 months ago the patch was posted to internals for review.
It included README files, TODO list, tests, tests, tests and explanations.
Few weeks later it got committed.
The commit got reviewed by various parties and some enhancements were made.
Every single procedure was followed to the letter.
People were happy.You cannot seriously be expecting more then that, nearly 4years later?
All I am asking is a single document in the central location we have dedicated for this (aka the rfc namespace on the wiki), that pulls together all relevant documentation. If all that is needed is a copy paste of a bunch of URL's all the better. But it makes no sense to ask each and every developer to "do his homework". Thats a waste of time and a sure way to have misunderstandings.
Seems like you know all there is to know about this, so how about just throwing together an RFC, shouldnt take more than 10 minutes if all of this is already perfectly documented.
Some links to get you started:
http://php.markmail.org/message/ujx2htvdzerrxgfe?q=README.NEW-OUTPUT-API+from:%22Michael+Wallner%22+order:date-forward
http://php.markmail.org/message/n22c6ye5boe2rtjk?q=README.NEW-OUTPUT-API+from:%22Michael+Wallner%22+order:date-forward&page=1
http://php.markmail.org/message/jgsd2umnm5lk37b6?q=README.NEW-OUTPUT-API+from:%22Michael+Wallner%22+order:date-forward&page=1
These links just highlight that there are questions, not that there are answers.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
All I am asking is a single document in the central location we have
dedicated for this (aka the rfc namespace on the wiki), that pulls
together all relevant documentation. If all that is needed is a copy
paste of a bunch of URL's all the better. But it makes no sense to
ask each and every developer to "do his homework". Thats a waste of
time and a sure way to have misunderstandings.Seems like you know all there is to know about this, so how about
just throwing together an RFC, shouldnt take more than 10 minutes if
all of this is already perfectly documented.
Here you go:
http://wiki.php.net/rfc/new-output-api
Cheers,
Mike
At 09:58 07/04/2010, Michael Wallner wrote:
Here you go:
Thanks Mike - that's very helpful!
Quick question - other than fixing the issues mentioned in the intro
section of the RFC, are there any changes to the behavior of
userland-accessible functions (ob_start(), etc.)?
Zeev
Am 07.04.2010 16:37, schrieb Zeev Suraski:
At 09:58 07/04/2010, Michael Wallner wrote:
Here you go:
Thanks Mike - that's very helpful!
Quick question - other than fixing the issues mentioned in the intro
section of the RFC, are there any changes to the behavior of
userland-accessible functions (ob_start(), etc.)?
It actually fixes quite some more oddities, but I really can't remember
what...
I'm also having quite a hard time remembering userland changes, but some
off the top of my head:
ob_start(array("oh1","oh2","oh3")) does not work, as the handler
argument is always supposed to be callable. This was undeocumented anyway.
ob_get_status() arrays have more/other entries.
ob_start("obh", 1) was supposed to really buffer just one byte, but
AFAIR this was changed back by someone to default to 4096...
ob_gzhandler() and thelike are no PHP_FUNCTIONs anymore.
Regards,
Mike
All I am asking is a single document in the central location we have
dedicated for this (aka the rfc namespace on the wiki), that pulls
together all relevant documentation. If all that is needed is a copy
paste of a bunch of URL's all the better. But it makes no sense to
ask each and every developer to "do his homework". Thats a waste of
time and a sure way to have misunderstandings.Seems like you know all there is to know about this, so how about
just throwing together an RFC, shouldnt take more than 10 minutes if
all of this is already perfectly documented.
Here you go:
http://wiki.php.net/rfc/new-output-api
Cheers,
Mike
hi Hannes,
On Wed, Mar 24, 2010 at 9:10 PM, Hannes Magnusson
hannes.magnusson@gmail.com wrote:
Hey,
Could one of you write up a short RFC on this patch? Just some details about the bugs fixed, known BC breaks and (undocumented) edge case changes. This would be helpful for anyone wanting to review their code and testing as well as documentation.
I really do not see why this even needs a discussion. Its been in
trunk for years already. People have had plenty of time to give
feedback.Is there really anyone who doesn't want this committed? For what reason?
In this case the RFC will help to:
- get a clear understanding about the changes
- explain how it affects the respective internals area
- helps to document the changes effectively
But it is really not about finding a reason not to commit this change
or discuss again whether or not we want it.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Hi!
I really do not see why this even needs a discussion. Its been in
trunk for years already. People have had plenty of time to give
feedback.Is there really anyone who doesn't want this committed? For what reason?
I don't think there's a reason not to commit it - but it also would be
very nice if we had some good explanation of what happens there, which
is in a place where it's easy to find. Not because the patch is bad or
something but because it'd be easy to work with it in the future this way.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com