5.3.1 process - Externals

15 years ago by johannes@php.net — view source

unread

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 to
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

15 years ago by Pierre Joye — view source

unread

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üter 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 to
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

--

--
Pierre

http://blog.thepimp.net | http://www.libgd.org

15 years ago by X Ryl — view source

unread

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üter 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 to
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

--

--
Pierre

http://blog.thepimp.net | http://www.libgd.org

15 years ago by Pierre Joye — view source

unread

hi,

No, this is actually a new feature and it actually more work than what
has been proposed in the various patches. We have trunk for the
development of new features.

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üter 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 to
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

--

--
Pierre

http://blog.thepimp.net | http://www.libgd.org

--

--
Pierre

http://blog.thepimp.net | http://www.libgd.org

15 years ago by Pierre Joye — view source

unread

hi Johannes,

I will begin to merge the changes we agreed on on Thursday (mines
only). I can't wait more as the diff between PHP_5_3 and PHP_5_3_1 is
getting large and it will make the merge harder, increasing the risk
to break things.

Cheers,

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üter 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 to
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

--

--
Pierre

http://blog.thepimp.net | http://www.libgd.org

--
Pierre

http://blog.thepimp.net | http://www.libgd.org