Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:45627
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.219.216 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:cc
         :content-type;
        b=bW2eb/P7U82qdqMHz8o/Smu0AigSwAhsrFAe0tW9dj13Y88jADKfyZAPfFCwuhfDsG
         EEKRMSSQbG79I8+ySfflCdcnfBOrr4zxRfMz4csyCjoyz5OT3ikiblRiU89egGG1GSkG
         slsev9SdfJHjlIejXkp2rREv7Oti1fUMJeu78=
MIME-Version: 1.0
In-Reply-To: <fe05d1540909190931t5ebab6b2i8af73a2a0b3db4f3@mail.gmail.com>
References: <1252015518.1733.104.camel@guybrush>
	 <fe05d1540909190931t5ebab6b2i8af73a2a0b3db4f3@mail.gmail.com>
Date: Tue, 22 Sep 2009 19:46:36 +0200
Message-ID: <5e33430b0909221046w3e917e56p96a9780c349568b4@mail.gmail.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary=00504502d35f034f8204742e2e80
Subject: Re: [PHP-DEV] 5.3.1 process
From: boite.pour.spam@gmail.com (X Ryl)

--00504502d35f034f8204742e2e80
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi, I would like to know if PHP 5.3.1 will fix the remanent big file (> 4GB=
)
issue on 32bits system.

There was 2 patch posted to fix this, the first one was in bug #48886 and
another one is there:
http://www.php.net/~wez/lfs.diff<http://www.php.net/%7Ewez/lfs.diff>

I don't know what is the expected protocol to get a patch examined, but I
hope you dev will at least try them.
I personnally have tried the one from bug #48886 and it's working as
described (it's using php's double to return/handle filesize when it can't
be stored in an 32bits int.
As the integral part of a double is 52bits wide, this give way larger space
for the filesize).
I haven't tried the new one from wez, but the previous one didn't work.

Hope it will get considered.
Regards,
X





2009/9/19 Pierre Joye <pierre.php@gmail.com>

> hi Johannes,
>
> It is a really great improvement that we don't have to worry anymore
> about being in a release phase for a given branch. However one thing I
> would like to improve in the merge frequency. Having a large merge the
> day (or the day before) a RC does not sound too god to me. It would be
> much safer to merge more often so we can valid them before the release
> or point you to some missing bits if necessary.
>
> Thoughts&comments welcome,
>
> Cheers,
>
> 2009/9/4 Johannes Schl=FCter <johannes@php.net>:
> > Hi,
> >
> > a new tool provides new opportunities and challenges, with the move to
> > svn I took some of the new possibilities and after many discussions
> > created a new release process which I'll try for 5.3.1 for which RC1 is
> > about to be packed. (having trouble accessing the snaps box to build
> > it...)
> >
> > The very short story for most devs is to go on and work on the branches
> > as before (meaning trunk, PHP_5_3, PHP_5_2, commit at once etc.)
> >
> > The longer story is this:
> >
> > I've created a new branch PHP_5_3_1. This release branch receives
> > selective merges by the RM (me) only!
> >
> > This branch will then be used to create RCs as often as needed
> > containing these fixes, as we won't have snaps for this branch only svn
> > checkouts and RCs will be available for testing. Therefore the aim is t=
o
> > provide stable RCs and the only change between the last RC and the
> > stable release shall be the version number change.
> >
> > Once 5.3.1 is to be published the PHP_5_3_1 branch will be converted
> > into a php_5_3_1 tag. (svn mv) And the 5.3.1 NEWS will be merged back
> > into PHP_5_3.
> >
> > When committing to PHP_5_3 please be conservative till 5.3.1 is out to
> > ease merging and testing (we have no snaps for PHP_5_3_1) and try to
> > indicate whether you think the change should be merged or not and tell
> > me if you think I missed to merge a commit.
> >
> > Once 5.3.1 is released this process will be reviewed and either be
> > documented or modified.
> >
> > Hoping this works out,
> > johannes
> >
> >
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>
>
>
> --
> Pierre
>
> http://blog.thepimp.net | http://www.libgd.org
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--00504502d35f034f8204742e2e80--