PHP 7.4 Release Manager Selection

Hi all!

With the first alpha of 7.4 due in three months, I think it's time to
start the process of finding and electing release managers for the next
minor release of PHP.

We are looking for two souls to take on this role. Whomsoever is
elected will be guided and helped by Stas and me, as well as previous
RMs and the excellent documentation in php-src:README.RELEASE_PROCESS.

Candidates should have a reasonable knowledge of internals (without
necessarily being a C guru), be confident about merging pull requests
without breaking backward compatibility, doing triage for bugs,
liaising with previous release managers, and generally getting the
branch in good shape, as these are among the activities you will be
undertaking as release manager.

Please put your name forward here if you wish to be considered a
candidate. An initial TODO page has been added to the wiki and contains
provisional dates for GA and pre-releases:
https://wiki.php.net/todo/php74

--
Christoph M. Becker

Em seg, 4 de mar de 2019 às 13:28, Christoph M. Becker cmbecker69@gmx.de
escreveu:

Hi all!

With the first alpha of 7.4 due in three months, I think it's time to
start the process of finding and electing release managers for the next
minor release of PHP.

We are looking for two souls to take on this role. Whomsoever is
elected will be guided and helped by Stas and me, as well as previous
RMs and the excellent documentation in php-src:README.RELEASE_PROCESS.

Candidates should have a reasonable knowledge of internals (without
necessarily being a C guru), be confident about merging pull requests
without breaking backward compatibility, doing triage for bugs,
liaising with previous release managers, and generally getting the
branch in good shape, as these are among the activities you will be
undertaking as release manager.

Please put your name forward here if you wish to be considered a
candidate. An initial TODO page has been added to the wiki and contains
provisional dates for GA and pre-releases:
https://wiki.php.net/todo/php74

--
Christoph M. Becker

--

I'd like to suggest Peter Kokot for this role.

Gabriel Caruso

Am 06.03.2019 um 01:18 schrieb Gabriel Caruso:

I'd like to suggest Peter Kokot for this role.

Seconded.

Am 06.03.2019 um 01:18 schrieb Gabriel Caruso:

I'd like to suggest Peter Kokot for this role.

Seconded.

Thirded.

Den ons. 6. mar. 2019 kl. 11.03 skrev Nikita Popov nikita.ppv@gmail.com:

Am 06.03.2019 um 01:18 schrieb Gabriel Caruso:

I'd like to suggest Peter Kokot for this role.

Seconded.

Thirded.

Fourthed.

--
regards,

Kalle Sommer Nielsen
kalle@php.net

Hi all,

It would be nice to hear from Peter , do you want to take on this role ?

You would have my vote, obviously, but we like people to volunteer, it's
not a small or short commitment.

Cheers
Joe

Den ons. 6. mar. 2019 kl. 11.03 skrev Nikita Popov nikita.ppv@gmail.com:

On Wed, Mar 6, 2019 at 6:20 AM Sebastian Bergmann sebastian@php.net
wrote:

Am 06.03.2019 um 01:18 schrieb Gabriel Caruso:

I'd like to suggest Peter Kokot for this role.

Seconded.

Thirded.

Fourthed.

--
regards,

Kalle Sommer Nielsen
kalle@php.net

Hello,

Hi all,

It would be nice to hear from Peter , do you want to take on this role ?

You would have my vote, obviously, but we like people to volunteer, it's
not a small or short commitment.

Cheers
Joe

Den ons. 6. mar. 2019 kl. 11.03 skrev Nikita Popov nikita.ppv@gmail.com:

On Wed, Mar 6, 2019 at 6:20 AM Sebastian Bergmann sebastian@php.net
wrote:

Am 06.03.2019 um 01:18 schrieb Gabriel Caruso:

I'd like to suggest Peter Kokot for this role.

Seconded.

Thirded.

Fourthed.

--
regards,

Kalle Sommer Nielsen
kalle@php.net

--

First of all, thank you for the nomination and suggestion. Yes, of
course, I'd be honoured to do that part. Overall, it's no secret I
still have a lot of catching up to do as far as PHP core is concerned,
but for the PHP 7.4 timeframe I can do that and will do my best to
provide quality releases on the set dates. If you think that I'm the
correct person for the PHP 7.4 release manager role already, let's do
it...

I also wanted to say that the quality level of the current PHP 7.2 and
7.3 release managers is really outstanding. I'll do my best to catch
such level.

Thank you and have a nice day forward from my side.

--
Peter Kokot

First of all, thank you for the nomination and suggestion. Yes, of
course, I'd be honoured to do that part. Overall, it's no secret I
still have a lot of catching up to do as far as PHP core is concerned,
but for the PHP 7.4 timeframe I can do that and will do my best to
provide quality releases on the set dates. If you think that I'm the
correct person for the PHP 7.4 release manager role already, let's do
it...

Excellent. Thank you Peter for accepting the call.

I also wanted to say that the quality level of the current PHP 7.2 and
7.3 release managers is really outstanding. I'll do my best to catch
such level.

Seconded. They've all been there when I had questions and have made the
process smooth and predictable.
Remi, Sara, Christoph, and Stas: thank you.

Hi all!

With the first alpha of 7.4 due in three months, I think it's time to
start the process of finding and electing release managers for the next
minor release of PHP.

We are looking for two souls to take on this role. Whomsoever is
elected will be guided and helped by Stas and me, as well as previous
RMs and the excellent documentation in php-src:README.RELEASE_PROCESS.

Candidates should have a reasonable knowledge of internals (without
necessarily being a C guru), be confident about merging pull requests
without breaking backward compatibility, doing triage for bugs,
liaising with previous release managers, and generally getting the
branch in good shape, as these are among the activities you will be
undertaking as release manager.

Please put your name forward here if you wish to be considered a
candidate. An initial TODO page has been added to the wiki and contains
provisional dates for GA and pre-releases:
https://wiki.php.net/todo/php74

Peter Kokot is willing to volunteer as release manager (thanks!) Is
someone willing to team up with Peter? Are there further candidates?

--
Christoph M. Becker

With the first alpha of 7.4 due in three months, I think it's time
to start the process of finding and electing release managers for
the next minor release of PHP.

We are looking for two souls to take on this role. Whomsoever is
elected will be guided and helped by Stas and me, as well as
previous RMs and the excellent documentation in
php-src:README.RELEASE_PROCESS.

Candidates should have a reasonable knowledge of internals (without
necessarily being a C guru), be confident about merging pull
requests without breaking backward compatibility, doing triage for
bugs, liaising with previous release managers, and generally getting
the branch in good shape, as these are among the activities you will
be undertaking as release manager.

Please put your name forward here if you wish to be considered a
candidate. An initial TODO page has been added to the wiki and
contains provisional dates for GA and pre-releases:
https://wiki.php.net/todo/php74

Peter Kokot is willing to volunteer as release manager (thanks!) Is
someone willing to team up with Peter? Are there further candidates?

I can help out.

cheers,
Derick

--
https://derickrethans.nl | https://xdebug.org | https://dram.io
Like Xdebug? Consider a donation: https://xdebug.org/donate.php,
or become my Patron: https://www.patreon.com/derickr
twitter: @derickr and @xdebug

With the first alpha of 7.4 due in three months, I think it's time
to start the process of finding and electing release managers for
the next minor release of PHP.

We are looking for two souls to take on this role. Whomsoever is
elected will be guided and helped by Stas and me, as well as
previous RMs and the excellent documentation in
php-src:README.RELEASE_PROCESS.

Candidates should have a reasonable knowledge of internals (without
necessarily being a C guru), be confident about merging pull
requests without breaking backward compatibility, doing triage for
bugs, liaising with previous release managers, and generally getting
the branch in good shape, as these are among the activities you will
be undertaking as release manager.

Please put your name forward here if you wish to be considered a
candidate. An initial TODO page has been added to the wiki and
contains provisional dates for GA and pre-releases:
https://wiki.php.net/todo/php74

Peter Kokot is willing to volunteer as release manager (thanks!) Is
someone willing to team up with Peter? Are there further candidates?

I can help out.

Great! Since we only have two volunteers, there's no need for a vote.

Ladies and gentlemen, I give you your PHP 7.4 Release Managers:

Peter Kokot and Derick Rethans

I suggest that both of you walk through the “New Release Manager
Checklist”[1] soonish, since it may take a while to actually get the
required karma (unless already granted).

[1]
https://github.com/php/php-src/blob/e67d872e3ea9c8d5d7fd96e7f20f15883bfe42ba/README.RELEASE_PROCESS#L379

--
Christoph M. Becker

On Mon, Mar 18, 2019 at 7:08 AM Christoph M. Becker cmbecker69@gmx.de
wrote:

Great! Since we only have two volunteers, there's no need for a vote.

Ladies and gentlemen, I give you your PHP 7.4 Release Managers:

Peter Kokot and Derick Rethans

Yay! And on that topic, did we come to a consensus on whether or not 7.4
was going to have an extended support cycle the way 5.6 did? If so, how
long was it?

-Sara

On Mon, Mar 18, 2019 at 7:08 AM Christoph M. Becker cmbecker69@gmx.de
wrote:

Great! Since we only have two volunteers, there's no need for a vote.

Ladies and gentlemen, I give you your PHP 7.4 Release Managers:

Peter Kokot and Derick Rethans

Yay! And on that topic, did we come to a consensus on whether or not 7.4
was going to have an extended support cycle the way 5.6 did? If so, how
long was it?

No, we have not (yet). :)

--
Christoph M. Becker

Le 18/03/2019 à 20:08, Sara Golemon a écrit :

Ladies and gentlemen, I give you your PHP 7.4 Release Managers:

Peter Kokot and Derick Rethans

Congrats to Peter and Derick !

Yay! And on that topic, did we come to a consensus on whether or not 7.4
was going to have an extended support cycle the way 5.6 did? If so, how
long was it?

5.6 support, as latest 5.x, was extended by 1 year

I think it make sense to do the same for latest 7.x
(so 2 years of security instead of 1)

Remi

Yay! And on that topic, did we come to a consensus on whether or not
7.4
was going to have an extended support cycle the way 5.6 did? If so, how
long was it?

5.6 support, as latest 5.x, was extended by 1 year

I think it make sense to do the same for latest 7.x
(so 2 years of security instead of 1)

I agree and think it's worth putting such into the release process as
standard practice.

-Sara

I'm not so sure it's worth adopting as policy. It's.my understanding that
5.6 was extended for reasons that may not apply to the 7.4-8 upgrade. It's
likely less painful, it's likely better prepared with 7.4 raising
appropriate deprecation notices and such.

At least I'd like someone to explain in detail why we should extend support
for 7.4?

Cheers
Joe

On Tue, Mar 19, 2019 at 9:49 AM Remi Collet remi@fedoraproject.org
wrote:

Yay! And on that topic, did we come to a consensus on whether or not
7.4
was going to have an extended support cycle the way 5.6 did? If so, how
long was it?

5.6 support, as latest 5.x, was extended by 1 year

I think it make sense to do the same for latest 7.x
(so 2 years of security instead of 1)

I agree and think it's worth putting such into the release process as
standard practice.

-Sara

Am 19.03.2019 um 17:43 schrieb Joe Watkins:

At least I'd like someone to explain in detail why we should extend support
for 7.4?

Seconded.

Den 2019-03-19 kl. 17:53, skrev Sebastian Bergmann:

Am 19.03.2019 um 17:43 schrieb Joe Watkins:

At least I'd like someone to explain in detail why we should extend
support
for 7.4?

Seconded.

For us the extended support of 5.6 has been very beneficial.
Primarily for two reasons:

• A large legacy code base that took time to fix.
• Adaption of third-party tools takes time. For instance latest
    version of smarty that we use, still gives error messages for
    PHP 7.3 (a standard plugin).

I don't expect the above to change going from 7.4 to 8.0. Of
course it depends on the 8.0 features and BC breaks.

Also looking at the 7.4 content it seems quite attractive! So
given that we don't yet know uptake of 8.0, 7.4 could have
a long lifespan.

Another point is that when looking in the control panel for
our server that incorporates PHP, 5.6.40 is listed as outdated.
If it had been a year ago instead (no extended support ), then
it would have felt weird since 5.6 has executed flawlessly in
2018 for us.

Finally, given that the extended support for 5.6 has been quite
a success, having the same for 7.4 seems prudent at this point
in time.

r//Björn L

They sound like justifications for 5.6 support being extended.

I think there are good reasons to stick to schedule for 7.4: 8.0 is certain
to contain JIT, 7.4 is not, but should 7.4 get the JIT then it will be
experimental, and because of ABI guarantees and BC concerns will be more or
less stale in the 7.4 branch, with a focus on 8. It will not be good to
have an experimental feature being used in production for an additional
year. If 7.4 doesn't get the JIT then that's a really good reason to
upgrade to 8, which will help adoption, and extending support will harm
adoption.

The upgrade from 7.4 to 8 for tools like smarty should be relatively
painless, if any changes are needed at all they will be quick and easy. The
same for third party extensions most likely ... This isn't comparable to
5.6 to 7 where rather a lot of extension code needed to be rewritten, and
userland code may have been broken.

What is clear is that we should not be adjusting policy with extended
support for the last release in a series, if we are going to extend support
then it should be for reasons beyond "it's the final release in this
series".

Cheers
Joe

Den 2019-03-19 kl. 17:53, skrev Sebastian Bergmann:

Am 19.03.2019 um 17:43 schrieb Joe Watkins:

At least I'd like someone to explain in detail why we should extend
support
for 7.4?

Seconded.

For us the extended support of 5.6 has been very beneficial.
Primarily for two reasons:

• A large legacy code base that took time to fix.
• Adaption of third-party tools takes time. For instance latest
  version of smarty that we use, still gives error messages for
  PHP 7.3 (a standard plugin).

I don't expect the above to change going from 7.4 to 8.0. Of
course it depends on the 8.0 features and BC breaks.

Also looking at the 7.4 content it seems quite attractive! So
given that we don't yet know uptake of 8.0, 7.4 could have
a long lifespan.

Another point is that when looking in the control panel for
our server that incorporates PHP, 5.6.40 is listed as outdated.
If it had been a year ago instead (no extended support ), then
it would have felt weird since 5.6 has executed flawlessly in
2018 for us.

Finally, given that the extended support for 5.6 has been quite
a success, having the same for 7.4 seems prudent at this point
in time.

r//Björn L