Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:76548
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.45 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAEZPtU4T5adqefPsMCVuQLstMZNKasn=1ZjPW-N+KU+VRhuMzg@mail.gmail.com>
References: <rnaqu9pp4im9uro4j52a5ocmtn4vkccgm2@4ax.com>
	<53ED5FD4.7000307@sugarcrm.com>
	<irfru9t93s4cli8eaeig56s9vf4n51cuu3@4ax.com>
	<CAEZPtU4T5adqefPsMCVuQLstMZNKasn=1ZjPW-N+KU+VRhuMzg@mail.gmail.com>
Date: Fri, 15 Aug 2014 12:31:10 +0200
Message-ID: <CAH-PCH7roBTC2GFZqhsoG81wBmMj=LBtMJjXiWLf+h7XAT3ciQ@mail.gmail.com>
To: Pierre Joye <pierre.php@gmail.com>
Cc: Jan Ehrhardt <phpdev@ehrhardt.nl>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c2ef7e16eaf00500a88538
Subject: Re: [PHP-DEV] Status of PHP 5.4
From: tyra3l@gmail.com (Ferenc Kovacs)

--001a11c2ef7e16eaf00500a88538
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, Aug 15, 2014 at 10:53 AM, Pierre Joye <pierre.php@gmail.com> wrote:

> On Fri, Aug 15, 2014 at 10:10 AM, Jan Ehrhardt <phpdev@ehrhardt.nl> wrote=
:
> > Stas Malyshev in php.internals (Thu, 14 Aug 2014 18:18:12 -0700):
> >>> PHP 5.3 has reached the real end of life. Will the effect be that fro=
m
> >>> now on PHP 5.4 will only get security fixes?
> >>
> >>There's no dependency between the two in the release RFC, but it would
> >>probably make sense to move 5.4 into "security only" phase once 5.6 is
> >>GA, and set EOL date for 1 year since that moment, as we did with 5.3.
> >
> > OK, given the fact that 'the stable 5.6.0 release should show up on the
> > 28th of August', this means that PHP 5.4.32 will be the last normal
> > release.
> >
> > PHP 5.4.33 up until PHP 5.4.44 will be 'security fixes only' releases.
>
> That being said I would like to understand the underlying reasons why
> 5.6 will get out two months late. I see nothing that should have
> justified it. I am not blaming anyone but it would be nice to see
> where we failed and try to improve that for the next releases.
>
>
the alpha1 was delayed because of the HTTP_RAW_POST_DATA BC break, which
took some time for us to come up with an acceptable resolution for all
parties.

alpha2 was delayed by a week because the windows snaps building wasn't
working (checking that is a mandatory step in the RM's checklist:
http://git.php.net/?p=3Dphp-src.git;a=3Dblob;f=3DREADME.RELEASE_PROCESS;h=
=3D7a82a5c61453bb436319d54ef88f7bc6090fa0a2;hb=3Drefs/heads/PHP-5.6#l59
)

alpha3 was delayed by a week, because I tagged two days later, and we had
some test failures on windows which all turned out problems with the tests
so we didn't had to re-tag, we ended up not announcing it on friday(and the
windows snap building was broken again).

beta1 was delayed by two weeks, mostly because the outstanding session
issues (there were some stuff which was accepted in an RFC, but not
commited, stuff which got committed but not being part of the rfc, and we
even had to revert stuff which was mentioned in the accepted RFC but later
good point where brought up to be reverted).

beta2 was delayed by a week, I can't find any particular reason, so it was
probably just me not having the time to test and tag in time.

beta3 was on time

beta4 was delayed by a week, I think it was because I was working on
improving our travis builds that time (and looking into cross compiling
32bit builds there because travis doesn't have 32bit VMs, but I got hit by
some ubuntu packages not properly supporting MultiArch installations)

RC1 was on time

RC2 was on time

RC3 was delayed by two weeks because we had to resolve the issue that 5.6
removes the ability for userland to instantiate any object via the O:
trick, and I wanted to provide them an upgrade path so I proposed
https://github.com/php/php-src/pull/733 for that.

RC4 was on time (maybe we could have skipped it, if the countable::count
changes are reverted a day sooner, or if I would tagged a day later).


If not considering giving up on quality, then I think there are only two
things we can really improve to elimiate the delays:
* there were a couple of cases where I felt that I had to put too much
effort into convincing some people that introducing a BC break for a no
feature is a no-go. to resolve this  we can either hope that people will
learn that this is our best interest and will be more cooperating, or we
can be a bit more strict and start using the RMs veto "karma" and revert
stuff if an issue brought up is not resolved in a timely manner.
* having only one dedicated RM (plus him having not comfortable enough with
the codebase) is less than optimal, Julien couldn't really put into 5.6 as
much time as he wanted to, because he already RMing an active release, and
traveling to confs, etc.

--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--001a11c2ef7e16eaf00500a88538--