PHP 7.4 Release Manager Selection

  104581
March 4, 2019 16:28 cmbecker69@gmx.de ("Christoph M. Becker")
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
  104591
March 6, 2019 00:18 carusogabriel34@gmail.com (Gabriel Caruso)
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 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > I'd like to suggest Peter Kokot for this role.
-- Gabriel Caruso
  104593
March 6, 2019 05:20 sebastian@php.net (Sebastian Bergmann)
Am 06.03.2019 um 01:18 schrieb Gabriel Caruso:
> I'd like to suggest Peter Kokot for this role.
Seconded.
  104599
March 6, 2019 09:02 nikita.ppv@gmail.com (Nikita Popov)
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.
  104602
March 6, 2019 09:39 kalle@php.net (Kalle Sommer Nielsen)
Den ons. 6. mar. 2019 kl. 11.03 skrev Nikita Popov 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
  104605
March 6, 2019 14:31 krakjoe@gmail.com (Joe Watkins)
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

On Wed, 6 Mar 2019 at 10:39, Kalle Sommer Nielsen <kalle@php.net> wrote:

> Den ons. 6. mar. 2019 kl. 11.03 skrev Nikita Popov 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 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
  104608
March 6, 2019 18:49 peterkokot@gmail.com (Peter Kokot)
Hello,
On Wed, 6 Mar 2019 at 15:31, Joe Watkins <krakjoe@gmail.com> wrote:
> > 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 > > On Wed, 6 Mar 2019 at 10:39, Kalle Sommer Nielsen <kalle@php.net> wrote: > > > Den ons. 6. mar. 2019 kl. 11.03 skrev Nikita Popov 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 > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > > >
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
  104609
March 6, 2019 20:03 bishop@php.net (Bishop Bettini)
On Wed, Mar 6, 2019 at 1:49 PM Peter Kokot <peterkokot@gmail.com> wrote:

> > 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.
  104654
March 11, 2019 14:11 cmbecker69@gmx.de ("Christoph M. Becker")
Hi all!

On 04.03.2019 at 17:28, Christoph M. Becker wrote:

> 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
  104656
March 11, 2019 14:19 derick@php.net (Derick Rethans)
On Mon, 11 Mar 2019, Christoph M. Becker wrote:

> On 04.03.2019 at 17:28, Christoph M. Becker wrote: > > > 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
  104784
March 18, 2019 12:08 cmbecker69@gmx.de ("Christoph M. Becker")
On 11.03.2019 at 15:19, Derick Rethans wrote:

> On Mon, 11 Mar 2019, Christoph M. Becker wrote: > >> On 04.03.2019 at 17:28, Christoph M. Becker wrote: >> >>> 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
  104787
March 18, 2019 19:08 pollita@php.net (Sara Golemon)
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
  104788
March 18, 2019 19:19 cmbecker69@gmx.de ("Christoph M. Becker")
On 18.03.2019 at 20:08, Sara Golemon wrote:

> 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
  104800
March 19, 2019 14:49 Remi Collet <remi@fedoraproject.org>
--eMsXRg0360cBeqFGV84w13Xc1lpFJnS2y
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

Le 18/03/2019 =C3=A0 20:08, Sara Golemon a =C3=A9crit=C2=A0:
>> 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= =2E4
> 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 --eMsXRg0360cBeqFGV84w13Xc1lpFJnS2y--
  104801
March 19, 2019 14:54 pollita@php.net (Sara Golemon)
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
  104803
March 19, 2019 16:43 krakjoe@gmail.com (Joe Watkins)
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, 19 Mar 2019, 15:54 Sara Golemon, <pollita@php.net> wrote:

> 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 >
  104804
March 19, 2019 16:53 sebastian@php.net (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.
  104806
March 19, 2019 19:50 bjorn.x.larsson@telia.com (=?UTF-8?Q?Bj=c3=b6rn_Larsson?=)
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
  104807
March 19, 2019 20:06 krakjoe@gmail.com (Joe Watkins)
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

On Tue, 19 Mar 2019, 20:50 Björn Larsson, larsson@telia.com> wrote:

> 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 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >