On 26.06.2009, at 17:26, Lukas Kahwe Smith wrote:
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 sol
2009/6/27 Johannes Schlüter :
> On Fri, 2009-06-26 at 20:40 -0400, Ilia Alshanetsky wrote:
>> After some conversations with Rasmus on IRC i've come up with the
>> following patch:
>>
>> http://ilia.ws/patch/curl.txt
>
> I this the latest patch and all agree t it? Or were there further
> improvement
On Fri, 2009-06-26 at 20:40 -0400, Ilia Alshanetsky wrote:
> After some conversations with Rasmus on IRC i've come up with the
> following patch:
>
> http://ilia.ws/patch/curl.txt
I this the latest patch and all agree t it? Or were there further
improvements?
Could somebody of you please commit
Hi,
On Fri, 2009-06-26 at 18:30 +0100, Scott MacVicar wrote:
> 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
obs
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
--
PHP Internals - PHP Runtime Development Mailing List
To uns
Ilia Alshanetsky wrote:
> After some conversations with Rasmus on IRC i've come up with the
> following patch:
>
> http://ilia.ws/patch/curl.txt
>
> This basically forces flush() on the header & output streams right after
> curl_exec(), this ensures that the data retrieved by curl is synched to
>
After some conversations with Rasmus on IRC i've come up with the
following patch:
http://ilia.ws/patch/curl.txt
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 con
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 =
Thanks Scott, it helps to save files before quitting ;-)
Here is the updated patch.
Ilia Alshanetsky
Index: ext/curl/interface.c
===
RCS file: /repository/php-src/ext/curl/interface.c,v
retrieving revision 1.62.2.14.2.57
diff -u -
You have an assignment instead of a comparison there.
Scott
On 27 Jun 2009, at 00:52, Ilia Alshanetsky wrote:
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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.
In
Pierre Joye wrote:
> On Fri, Jun 26, 2009 at 9:11 PM, Rasmus Lerdorf 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
On Fri, Jun 26, 2009 at 22:35, Scott MacVicar wrote:
> 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.
Howeve
this process is known and we already said that we have to change the
way we do it after 5.3.0.
On Fri, Jun 26, 2009 at 10:35 PM, Scott MacVicar wrote:
> 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 bei
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 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 9:
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 gettin
On 26 Jun 2009, at 19:59, Lukas Kahwe Smith wrote:
On 26.06.2009, at 20:26, Pierre Joye wrote:
On Fri, Jun 26, 2009 at 7:30 PM, Scott MacVicar
wrote:
On 26 Jun 2009, at 16:26, Lukas Kahwe Smith wrote:
Aloha,
So the last fix is just being prepared for a commit and so we
will be
tagging
Pierre Joye wrote:
> On Fri, Jun 26, 2009 at 9:11 PM, Rasmus Lerdorf 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
On Fri, Jun 26, 2009 at 9:11 PM, Rasmus Lerdorf 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 puttin
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
On 26.06.2009, at 20:26, Pierre Joye wrote:
On Fri, Jun 26, 2009 at 7:30 PM, Scott MacVicar
wrote:
On 26 Jun 2009, at 16:26, Lukas Kahwe Smith 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
On Fri, Jun 26, 2009 at 7:30 PM, Scott MacVicar wrote:
> On 26 Jun 2009, at 16:26, Lukas Kahwe Smith 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
>
On Jun 26, 2009, at 2:22 PM, Hannes Magnusson wrote:
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
On Fri, Jun 26, 2009 at 17:26, Lukas Kahwe Smith wrote:
> 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
--
PHP Internals - PHP Runtime Development Mailing
On 26-Jun-09, at 1:30 PM, Scott MacVicar wrote:
On 26 Jun 2009, at 16:26, Lukas Kahwe Smith 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
On 26 Jun 2009, at 16:26, Lukas Kahwe Smith 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 frustrati
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, w
28 matches
Mail list logo
