Aloha,
So the last fix is just being prepared for a commit and so we will be
tagging 5.3.0 soon.
We would like to up hold the commit freeze until 5.3.0 is announced
next Tuesday.
After this period bug fixes can be applied again. However feature
additions should wait until after 5.3.1, which we expect to be
released within a month or two. As always if you are unsure, ask
Johannes. And also as always if there is a solid reason, common sense
rules, but please do ask first.
regards,
Johannes and Lukas
Aloha,
So the last fix is just being prepared for a commit and so we will
be tagging 5.3.0 soon.We would like to up hold the commit freeze until 5.3.0 is announced
next Tuesday.
This freeze that you guys have implemented is frustrating, just branch
5_3 into a release branch and Johannes can take selective fixes from
5_3 as needed.
We all know your reasons for the freeze and agree with it but holding
up regular development is a PITA.
Scott
Aloha,
So the last fix is just being prepared for a commit and so we will
be tagging 5.3.0 soon.We would like to up hold the commit freeze until 5.3.0 is announced
next Tuesday.This freeze that you guys have implemented is frustrating, just
branch 5_3 into a release branch and Johannes can take selective
fixes from 5_3 as needed.
+1
A long term freeze will simply mean that some bug fixes will be missed
in the 5.3 release and we'd end up with a less stable version in the
long term. I know it makes release cycle that much simpler, but lets
make sure we don't stall the development.
Aloha,
So the last fix is just being prepared for a commit and so we will be
tagging 5.3.0 soon.We would like to up hold the commit freeze until 5.3.0 is announced next
Tuesday.This freeze that you guys have implemented is frustrating, just branch 5_3
into a release branch and Johannes can take selective fixes from 5_3 as
needed.We all know your reasons for the freeze and agree with it but holding up
regular development is a PITA.
It is not holding up development. It is about getting a viable release
cycle and to give us the minimum safety to release 5.3.1 in a
reasonable time frame. Please explain me what's wrong to allow only
bug fixes for this phase?
Also please note that we have HEAD for all the developments and new features.
Cheers,
Pierre
On Fri, Jun 26, 2009 at 7:30 PM, Scott MacVicarscott@macvicar.net
wrote:Aloha,
So the last fix is just being prepared for a commit and so we will
be
tagging 5.3.0 soon.We would like to up hold the commit freeze until 5.3.0 is
announced next
Tuesday.This freeze that you guys have implemented is frustrating, just
branch 5_3
into a release branch and Johannes can take selective fixes from
5_3 as
needed.We all know your reasons for the freeze and agree with it but
holding up
regular development is a PITA.It is not holding up development. It is about getting a viable release
cycle and to give us the minimum safety to release 5.3.1 in a
reasonable time frame. Please explain me what's wrong to allow only
bug fixes for this phase?Also please note that we have HEAD for all the developments and new
features.
Exactly.
I will do my best to track things that need to be merged. Best is to
note if something needs to be merged.
But if you all feel it's such a huge burden then you can of course
insist on putting the burden on the RMs. The fact of the matter is
that our current infrastructure is not fit for providing both sides
with an efficient solution.
Regards,
Lukas
Lukas Kahwe Smith wrote:
Exactly.
I will do my best to track things that need to be merged. Best is to
note if something needs to be merged.But if you all feel it's such a huge burden then you can of course
insist on putting the burden on the RMs. The fact of the matter is that
our current infrastructure is not fit for providing both sides with an
efficient solution.
Keep an eye on http://bugs.php.net/48518
I don't think we can let 5.3 out the door with this regression.
-Rasmus
Lukas Kahwe Smith wrote:
Exactly.
I will do my best to track things that need to be merged. Best is to
note if something needs to be merged.But if you all feel it's such a huge burden then you can of course
insist on putting the burden on the RMs. The fact of the matter is that
our current infrastructure is not fit for providing both sides with an
efficient solution.Keep an eye on http://bugs.php.net/48518
I don't think we can let 5.3 out the door with this regression.
btw, 5.2.10 is out too with this regression. If I'm not mistaken.
Cheers,
Pierre
Pierre Joye wrote:
Lukas Kahwe Smith wrote:
Exactly.
I will do my best to track things that need to be merged. Best is to
note if something needs to be merged.But if you all feel it's such a huge burden then you can of course
insist on putting the burden on the RMs. The fact of the matter is that
our current infrastructure is not fit for providing both sides with an
efficient solution.
Keep an eye on http://bugs.php.net/48518I don't think we can let 5.3 out the door with this regression.
btw, 5.2.10 is out too with this regression. If I'm not mistaken.
It is, and it is causing some nasty headaches because it is non-trivial
to debug.
-Rasmus
Pierre Joye wrote:
Lukas Kahwe Smith wrote:
Exactly.
I will do my best to track things that need to be merged. Best is to
note if something needs to be merged.But if you all feel it's such a huge burden then you can of course
insist on putting the burden on the RMs. The fact of the matter is that
our current infrastructure is not fit for providing both sides with an
efficient solution.
Keep an eye on http://bugs.php.net/48518I don't think we can let 5.3 out the door with this regression.
btw, 5.2.10 is out too with this regression. If I'm not mistaken.
Ok, I am running out of time for this one today.
As Tony mentioned in his original bug report for 48518:
Simple patch fixes this problem, but there is another one to consider:
should the refcount be decreased when closing the cURL handle?
That would be a yes. I don't see an easy way to relate an open
File-Handle resource back to the curl handle though short of walking all
open file handles and checking them against the fps in the curl struct,
or creating a separate llist for these resources tied to the curl
handle. If someone has an idea for a clean fix here, please speak up.
Second, because there was no addref on the fp before, a simple
curl_exec($ch);
fclose($fp);
would force a flush and the data would be available in the file. Even
if we decrement the refcount on the file handle resource in the curl
handle destructor, that still doesn't bring us back to that behaviour
because the fclose there doesn't actually close the file yet, as it
shouldn't. So here, a secondary fix, and a side-effect of this issue,
is that we should probably force a flush on the fclose for any flushable
streams we try to close when there are outstanding references holding
them open.
I think doing both of these should take care of this one.
And 10 years ago I'd be hacking on this for the next 3 hours, but right
now I am spending the next 3 hours picking up Carl from Lego Camp and
taking him to his piano lesson...
-Rasmus
Here is the least intrusive fix I can come up for this bug. When doing
curl_close() the dtor will force flush of data on a file stream
synching the data to disk. As far as I can tell (using Rasmus'
example) this appears to adequately fix the problem and I see no
immediate side-effects.
You have an assignment instead of a comparison there.
Scott
<curl.txt
Thanks Scott, it helps to save files before quitting ;-)
Here is the updated patch.
Ilia Alshanetsky
Just to keep the list in synch with the irc discussion. I pointed out
that this is only half of the fix. The refcount still prevents fclose
from flushing the data, so if you do:
$url = 'http://slowgeek.com/test.xml';
$cfile = 'out.xml';
$ch = curl_init($url);
curl_setopt($ch, CURLOPT_FILE, $fp = fopen($cfile,'w'));
$status = curl_exec($ch);
fclose($fp);
$data = file_get_contents($cfile);
var_dump($data); // 0 bytes here
curl_close($ch);
$data = file_get_contents($cfile);
var_dump($data); // full contents here
I still think we need to look at doing a flush on an fclose which
doesn't reach the stream destructor due to refcount issues.
Can anybody think of any side-effects of a flush on a stream close?
-Rasmus
After some conversations with Rasmus on IRC i've come up with the
following patch:
This basically forces flush() on the header & output streams right
after curl_exec(), this ensures that the data retrieved by curl is
synched to disk. The patch is also self contained to curl so no
external elements are affected by the patch.
Ilia Alshanetsky
Just to keep the list in synch with the irc discussion. I pointed out
that this is only half of the fix. The refcount still prevents fclose
from flushing the data, so if you do:$url = 'http://slowgeek.com/test.xml';
$cfile = 'out.xml';
$ch = curl_init($url);
curl_setopt($ch, CURLOPT_FILE, $fp = fopen($cfile,'w'));
$status = curl_exec($ch);
fclose($fp);
$data = file_get_contents($cfile);
var_dump($data); // 0 bytes here
curl_close($ch);
$data = file_get_contents($cfile);
var_dump($data); // full contents hereI still think we need to look at doing a flush on an fclose which
doesn't reach the stream destructor due to refcount issues.Can anybody think of any side-effects of a flush on a stream close?
-Rasmus
Ilia Alshanetsky wrote:
After some conversations with Rasmus on IRC i've come up with the
following patch:This basically forces
flush()on the header & output streams right after
curl_exec(), this ensures that the data retrieved by curl is synched to
disk. The patch is also self contained to curl so no external elements
are affected by the patch.
This looks good to me. It means 5.2.9 code will keep working. The only
slight behavioural change where the fp is now flushed before the
fclose/curl_close, but if anybody relied on a read at that point not
returning the last buffer, they deserve what they get.
This needs to go into all branches and let's re-tag and re-package 5.3
with this, Andrei's calloc fix, and the UPGRADING fixes.
-Rasmus
After some conversations with Rasmus on IRC i've come up with the
following patch:
I this the latest patch and all agree t it? Or were there further
improvements?
Could somebody of you please commit it then to 5.3 thanks.
johannes
2009/6/27 Johannes Schlüter johannes@php.net:
After some conversations with Rasmus on IRC i've come up with the
following patch:I this the latest patch and all agree t it? Or were there further
improvements?
Could somebody of you please commit it then to 5.3 thanks.
done (5.2/3, 6)
--
Pierre
Rasmus Lerdorf wrote:
And 10 years ago I'd be hacking on this for the next 3 hours, but right
now I am spending the next 3 hours picking up Carl from Lego Camp and
taking him to his piano lesson...
What, no cello lesson?
Greg
On Fri, Jun 26, 2009 at 7:30 PM, Scott MacVicarscott@macvicar.net
wrote:Aloha,
So the last fix is just being prepared for a commit and so we
will be
tagging 5.3.0 soon.We would like to up hold the commit freeze until 5.3.0 is
announced next
Tuesday.This freeze that you guys have implemented is frustrating, just
branch 5_3
into a release branch and Johannes can take selective fixes from
5_3 as
needed.We all know your reasons for the freeze and agree with it but
holding up
regular development is a PITA.It is not holding up development. It is about getting a viable
release
cycle and to give us the minimum safety to release 5.3.1 in a
reasonable time frame. Please explain me what's wrong to allow only
bug fixes for this phase?Also please note that we have HEAD for all the developments and new
features.Exactly.
I will do my best to track things that need to be merged. Best is to
note if something needs to be merged.But if you all feel it's such a huge burden then you can of course
insist on putting the burden on the RMs. The fact of the matter is
that our current infrastructure is not fit for providing both sides
with an efficient solution.
If we're freezing some more after this release for the SVN conversion
then we could have a pretty cold branch for another week or so.
As I've already said, I agree with only allow verified bug fixes by
Johannes into 5.3.0. it's this extra bureaucracy that is getting added
on top that's sucking hard.
I don't want to leave it up to someone else to merge it into 5.3, I
should be doing it myself. It's possible that things could get
accidentally missed wen someone else is applying it.
Scott
Scott MacVicar wrote:
If we're freezing some more after this release for the SVN conversion
then we could have a pretty cold branch for another week or so.As I've already said, I agree with only allow verified bug fixes by
Johannes into 5.3.0. it's this extra bureaucracy that is getting added
on top that's sucking hard.I don't want to leave it up to someone else to merge it into 5.3, I
should be doing it myself. It's possible that things could get
accidentally missed wen someone else is applying it.
I completely agree, which is why the solution is:
- commit to HEAD
- send a message to internals CC lukas with a link to the commit message
- after the freeze is over, Lukas forwards your message back to you,
and you do the merge.
Greg
you totally misunderstood the mail. The freeze is about the days
between now and the release itself on Tuesday (monday evening
actually). That's perfectly valid.
The idea then is to allow only bug fixes in 5.3.1, and only bug fixes.
What's wrong with that?
--
Pierre
On Fri, Jun 26, 2009 at 7:30 PM, Scott MacVicarscott@macvicar.net
wrote:Aloha,
So the last fix is just being prepared for a commit and so we will be
tagging 5.3.0 soon.We would like to up hold the commit freeze until 5.3.0 is announced
next
Tuesday.This freeze that you guys have implemented is frustrating, just branch
5_3
into a release branch and Johannes can take selective fixes from 5_3 as
needed.We all know your reasons for the freeze and agree with it but holding up
regular development is a PITA.It is not holding up development. It is about getting a viable release
cycle and to give us the minimum safety to release 5.3.1 in a
reasonable time frame. Please explain me what's wrong to allow only
bug fixes for this phase?Also please note that we have HEAD for all the developments and new
features.Exactly.
I will do my best to track things that need to be merged. Best is to note
if something needs to be merged.But if you all feel it's such a huge burden then you can of course insist
on putting the burden on the RMs. The fact of the matter is that our current
infrastructure is not fit for providing both sides with an efficient
solution.If we're freezing some more after this release for the SVN conversion then
we could have a pretty cold branch for another week or so.As I've already said, I agree with only allow verified bug fixes by Johannes
into 5.3.0. it's this extra bureaucracy that is getting added on top that's
sucking hard.I don't want to leave it up to someone else to merge it into 5.3, I should
be doing it myself. It's possible that things could get accidentally missed
wen someone else is applying it.Scott
--
Pierre
I completely agree with making sure 5.3.0 is stable and stopping
extra things sneaking their way in. I just don't like the way that it
is being done.
If the release is tagged and built, then why continue with the freeze?
Why not open it up for bug fixes towards 5.3.1?
If the reason that you're about to be given is, we might find
something critical and need to re-roll 5.3.0 then branch from the tag
you've created, fix what's needed and re-tag. Even though CVS sucks it
does allow this.
This is the way the Mozilla project has done it for years, following
their example we'd just create a PHP_5_3_RELBRANCH and work from that.
The RMs are the only ones that get to decide what goes in after the
freeze.
https://wiki.mozilla.org/SeaMonkey:Release_Process
Scott
you totally misunderstood the mail. The freeze is about the days
between now and the release itself on Tuesday (monday evening
actually). That's perfectly valid.The idea then is to allow only bug fixes in 5.3.1, and only bug fixes.
What's wrong with that?--
PierreOn Fri, Jun 26, 2009 at 9:26 PM, Scott MacVicarscott@macvicar.net
wrote:On Fri, Jun 26, 2009 at 7:30 PM, Scott MacVicarscott@macvicar.net
wrote:Aloha,
So the last fix is just being prepared for a commit and so we
will be
tagging 5.3.0 soon.We would like to up hold the commit freeze until 5.3.0 is
announced
next
Tuesday.This freeze that you guys have implemented is frustrating, just
branch
5_3
into a release branch and Johannes can take selective fixes from
5_3 as
needed.We all know your reasons for the freeze and agree with it but
holding up
regular development is a PITA.It is not holding up development. It is about getting a viable
release
cycle and to give us the minimum safety to release 5.3.1 in a
reasonable time frame. Please explain me what's wrong to allow only
bug fixes for this phase?Also please note that we have HEAD for all the developments and new
features.Exactly.
I will do my best to track things that need to be merged. Best is
to note
if something needs to be merged.But if you all feel it's such a huge burden then you can of course
insist
on putting the burden on the RMs. The fact of the matter is that
our current
infrastructure is not fit for providing both sides with an efficient
solution.If we're freezing some more after this release for the SVN
conversion then
we could have a pretty cold branch for another week or so.As I've already said, I agree with only allow verified bug fixes by
Johannes
into 5.3.0. it's this extra bureaucracy that is getting added on
top that's
sucking hard.I don't want to leave it up to someone else to merge it into 5.3, I
should
be doing it myself. It's possible that things could get
accidentally missed
wen someone else is applying it.
this process is known and we already said that we have to change the
way we do it after 5.3.0.
I completely agree with making sure 5.3.0 is stable and stopping extra
things sneaking their way in. I just don't like the way that it is being
done.If the release is tagged and built, then why continue with the freeze? Why
not open it up for bug fixes towards 5.3.1?If the reason that you're about to be given is, we might find something
critical and need to re-roll 5.3.0 then branch from the tag you've created,
fix what's needed and re-tag. Even though CVS sucks it does allow this.This is the way the Mozilla project has done it for years, following their
example we'd just create a PHP_5_3_RELBRANCH and work from that. The RMs are
the only ones that get to decide what goes in after the freeze.https://wiki.mozilla.org/SeaMonkey:Release_Process
Scott
you totally misunderstood the mail. The freeze is about the days
between now and the release itself on Tuesday (monday evening
actually). That's perfectly valid.The idea then is to allow only bug fixes in 5.3.1, and only bug fixes.
What's wrong with that?--
PierreOn Fri, Jun 26, 2009 at 7:30 PM, Scott MacVicarscott@macvicar.net
wrote:Aloha,
So the last fix is just being prepared for a commit and so we will be
tagging 5.3.0 soon.We would like to up hold the commit freeze until 5.3.0 is announced
next
Tuesday.This freeze that you guys have implemented is frustrating, just branch
5_3
into a release branch and Johannes can take selective fixes from 5_3
as
needed.We all know your reasons for the freeze and agree with it but holding
up
regular development is a PITA.It is not holding up development. It is about getting a viable release
cycle and to give us the minimum safety to release 5.3.1 in a
reasonable time frame. Please explain me what's wrong to allow only
bug fixes for this phase?Also please note that we have HEAD for all the developments and new
features.Exactly.
I will do my best to track things that need to be merged. Best is to
note
if something needs to be merged.But if you all feel it's such a huge burden then you can of course
insist
on putting the burden on the RMs. The fact of the matter is that our
current
infrastructure is not fit for providing both sides with an efficient
solution.If we're freezing some more after this release for the SVN conversion
then
we could have a pretty cold branch for another week or so.As I've already said, I agree with only allow verified bug fixes by
Johannes
into 5.3.0. it's this extra bureaucracy that is getting added on top
that's
sucking hard.I don't want to leave it up to someone else to merge it into 5.3, I
should
be doing it myself. It's possible that things could get accidentally
missed
wen someone else is applying it.
--
Pierre
If the reason that you're about to be given is, we might find something
critical and need to re-roll 5.3.0 then branch from the tag you've created,
fix what's needed and re-tag. Even though CVS sucks it does allow this.
Fair enough.
However. You should still be committing to HEAD before 5_whatever.
And we are about to switch from SVN.
Lets keep the release model as-is for 3more days, migrate to SVN and
then design a better release model.
-Hannes
p.s. I missed the tagging by an hour, so I feel your frustration - but
you should be developing in the developer branch, not release
branch...
Hi,
This freeze that you guys have implemented is frustrating, just branch
5_3 into a release branch and Johannes can take selective fixes from
5_3 as needed.
In my experience - from projects I participated as well were I just
observed - release branches with CVS often end with more pain than
freezes. It is of course hard to predict what would happen in this
project with these developers in this situation.
And well, as said 5.3 is a quite big release and has many things where
errors can be introduced and I guess we all want it out soonish as
stable as possible ...
We all know your reasons for the freeze and agree with it but holding
up regular development is a PITA.
HEAD is the development branch. 5.3 should only get stable stuff
anyways. And I assume you are committing only well tested stuff to 5.3
which means you have some way of management outside CVS assisting you
during development and testing of your stuff.
About the extension of the freeze for the migration: I think we first
should have a window for getting some fixes in before doing the
migration so at least some of the backlog can be cleared. As far as I
know there's n final complete migration plan and there might be people
who want to play a little with the test repo once 5.3 is out.
johannes
We would like to up hold the commit freeze until 5.3.0 is announced next
Tuesday.
And the move to SVN? It'll require a complete cvs.php.net freeze for
couple of days, I think?
-Hannes
We would like to up hold the commit freeze until 5.3.0 is announced
next
Tuesday.
And the move to SVN? It'll require a complete cvs.php.net freeze for
couple of days, I think?
Yes, but it's not ready for that yet; an unfreeze after 5.3's release
won't kill anyway. But keep in mind that the SVN freeze will freeze
PEAR and PECL and GTK and... well, everyone. Once CVS write access is
shut off, it'll never be turned back on (unless there's a problem with
SVN). Whereas this freeze is just on PHP itself.
-- Gwynne
After this period bug fixes can be applied again. However feature
additions should wait until after 5.3.1, which we expect to be
released within a month or two. As always if you are unsure, ask
Johannes. And also as always if there is a solid reason, common
sense rules, but please do ask first.
Ok, so we are in the process of announcing 5.3.0. So you can now go
ahead and commit bug fixes without prior review into 5_3. Please hold
off from feature additions for now or bring them up on internals if
you feel they are urgent.
I will start notifying developer about bug fixes that should be merged
now.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org