[RFC] [VOTE] PHP 5's Support Timeline

9 years ago by Derick Rethans — view source — reply

unread

Hi,

just bumping this so that there is less chance this gets lost in the CoC
thread :-)

cheers,
Derick

Hopefully mostly everyone is back from the holidays by now, the vote is now
open for the PHP 5 Support Timeline RFC:

https://wiki.php.net/rfc/php56timeline#vote

Voting ends January 13th 2016 at 10:00am GMT.

Thanks!

Zeev

--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Posted with an email client that doesn't mangle email: alpine

9 years ago by Pascal MARTIN — view source — reply

unread

Le 05/01/2016 10:51, Zeev Suraski a écrit :

the vote is now
open for the PHP 5 Support Timeline RFC:

https://wiki.php.net/rfc/php56timeline#vote

Hi,

We've discussed this at length at AFUP, and would be +1 to extend the
lifetime of PHP 5, by a huge margin.

As for the duration, we would be on the 1+1 year side, by a smaller margin.

Basically:

Not everyone will switch to PHP 7 right away, so extending support,
especially for security, seems necessary.
But extending it for too long could give a wrong message to some
users, like "no need to upgrade"; and we don't want that.
Also, after a while, we would prefer time being spent on 7.x instead
of used maintaining 5.x for years.
And, in any case, some users will never upgrade, no matter how long
5.x is maintained... that's just how it is.

Thanks

--
Pascal MARTIN, AFUP - French UG
http://php-internals.afup.org/

9 years ago by Zeev Suraski — view source — reply

unread

All,

The vote has been closed. It was approved 42 to 2 (95.5% in favor).
There was a close race between the two available extended schedules, and the one selected is Active Support until December 31st 2016, and Security Support until December 31st 2018.

Thanks to everyone who participated & voted!

Zeev

From: Zeev Suraski
Sent: Tuesday, January 05, 2016 11:52 AM
To: PHP internals internals@lists.php.net
Subject: [RFC] [VOTE] PHP 5's Support Timeline

Hopefully mostly everyone is back from the holidays by now, the vote is now open for the PHP 5 Support Timeline RFC:

https://wiki.php.net/rfc/php56timeline#vote

Voting ends January 13th 2016 at 10:00am GMT.

Thanks!

Zeev

9 years ago by Joe Watkins — view source — reply

unread

The no votes should be counted as votes for option one schedule.

Which makes the vote a tie, and if any changes are going to be made, we
should be using option 1 schedule, not 2 ...

Cheers
Joe

All,

The vote has been closed. It was approved 42 to 2 (95.5% in favor).
There was a close race between the two available extended schedules, and
the one selected is Active Support until December 31st 2016, and Security
Support until December 31st 2018.

Thanks to everyone who participated & voted!

Zeev

From: Zeev Suraski
Sent: Tuesday, January 05, 2016 11:52 AM
To: PHP internals internals@lists.php.net
Subject: [RFC] [VOTE] PHP 5's Support Timeline

Hopefully mostly everyone is back from the holidays by now, the vote is
now open for the PHP 5 Support Timeline RFC:

https://wiki.php.net/rfc/php56timeline#vote

Voting ends January 13th 2016 at 10:00am GMT.

Thanks!

Zeev

9 years ago by Bob Weinand — view source — reply

unread

I agree,

no votes should be meaning "I want as less as possible support".
Counting it that way would make it up for a tie and us choosing the most restrictive schedule as a result.
(Interpreting it like "you need 50%+1 of the total to get it extended so far".)

Hence Security Support until Dec 31 2017.

Bob

Am 13.01.2016 um 14:02 schrieb Joe Watkins pthreads@pthreads.org:

The no votes should be counted as votes for option one schedule.

Which makes the vote a tie, and if any changes are going to be made, we
should be using option 1 schedule, not 2 ...

Cheers
Joe

All,

The vote has been closed. It was approved 42 to 2 (95.5% in favor).
There was a close race between the two available extended schedules, and
the one selected is Active Support until December 31st 2016, and Security
Support until December 31st 2018.

Thanks to everyone who participated & voted!

Zeev

From: Zeev Suraski
Sent: Tuesday, January 05, 2016 11:52 AM
To: PHP internals internals@lists.php.net
Subject: [RFC] [VOTE] PHP 5's Support Timeline

Hopefully mostly everyone is back from the holidays by now, the vote is
now open for the PHP 5 Support Timeline RFC:

https://wiki.php.net/rfc/php56timeline#vote

Voting ends January 13th 2016 at 10:00am GMT.

Thanks!

Zeev

9 years ago by Peter Cowburn — view source — reply

unread

I agree,

no votes should be meaning "I want as less as possible support".
Counting it that way would make it up for a tie and us choosing the most
restrictive schedule as a result.
(Interpreting it like "you need 50%+1 of the total to get it extended so
far".)

As the RFC describes, the "no votes" were voting for "no change", i.e. the
8 month + 1 year schedule.

The second poll was conditional on having voted "yes" in the first poll.
There were two voters who didn't vote "yes" for the first poll who voted on
the second poll, but as they chose different options the conclusion doesn't
change.

Hence Security Support until Dec 31 2017.

Bob

Am 13.01.2016 um 14:02 schrieb Joe Watkins pthreads@pthreads.org:

The no votes should be counted as votes for option one schedule.

Which makes the vote a tie, and if any changes are going to be made, we
should be using option 1 schedule, not 2 ...

Cheers
Joe

All,

The vote has been closed. It was approved 42 to 2 (95.5% in favor).
There was a close race between the two available extended schedules, and
the one selected is Active Support until December 31st 2016, and
Security
Support until December 31st 2018.

Thanks to everyone who participated & voted!

Zeev

From: Zeev Suraski
Sent: Tuesday, January 05, 2016 11:52 AM
To: PHP internals internals@lists.php.net
Subject: [RFC] [VOTE] PHP 5's Support Timeline

Hopefully mostly everyone is back from the holidays by now, the vote is
now open for the PHP 5 Support Timeline RFC:

https://wiki.php.net/rfc/php56timeline#vote

Voting ends January 13th 2016 at 10:00am GMT.

Thanks!

Zeev

9 years ago by Zeev Suraski — view source — reply

unread

-----Original Message-----
From: Bob Weinand [mailto:bobwei9@hotmail.com]
Sent: Wednesday, January 13, 2016 3:16 PM
To: Zeev Suraski zeev@zend.com
Cc: Joe Watkins pthreads@pthreads.org; PHP internals
internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] [VOTE] PHP 5's Support Timeline

I agree,

no votes should be meaning "I want as less as possible support".
Counting it that way would make it up for a tie and us choosing the most
restrictive schedule as a result.
(Interpreting it like "you need 50%+1 of the total to get it extended so far".)

Hence Security Support until Dec 31 2017.

Bob,

The way the RFC the choices are going to be interpreted was presented ahead of time, was available throughout the entire discussion period, and very clearly so:
"In case the majority chooses to extend the lifetime of PHP 5.6 (>50%) - then the option garnering more votes between the two proposed timelines would win."

I'm not sure what the situation would have been had we truly had a 23/23 split, probably a revote or an extended voting period, but the current situation is very well defined under the RFC terms.

Thanks,

Zeev

9 years ago by Derick Rethans — view source — reply

unread

From: Bob Weinand [mailto:bobwei9@hotmail.com]

no votes should be meaning "I want as less as possible support".
Counting it that way would make it up for a tie and us choosing the most
restrictive schedule as a result.
(Interpreting it like "you need 50%+1 of the total to get it extended so far".)

Hence Security Support until Dec 31 2017.

The way the RFC the choices are going to be interpreted was presented ahead of time, was available throughout the entire discussion period, and very clearly so:
"In case the majority chooses to extend the lifetime of PHP 5.6 (>50%) - then the option garnering more votes between the two proposed timelines would win."

I'm not sure what the situation would have been had we truly had a 23/23 split, probably a revote or an extended voting period, but the current situation is very well defined under the RFC terms.

Not that I particularly care about this outcome, but there were only
"42" Yes votes, and "2" No votes. As the voting says for the second part
"ONLY IF YOU CHOSE 'YES' ABOVE: ", there should only be 42 votes in the
second part, and not 44 like there are now (21+23)... so there is
something wonky.

I would recommend, not to do split votes like this anymore. It's just
too confusing IMO.

cheers,
Derick

9 years ago by Ferenc Kovacs — view source — reply

unread

From: Bob Weinand [mailto:bobwei9@hotmail.com]

no votes should be meaning "I want as less as possible support".
Counting it that way would make it up for a tie and us choosing the
most
restrictive schedule as a result.
(Interpreting it like "you need 50%+1 of the total to get it extended
so far".)

Hence Security Support until Dec 31 2017.

The way the RFC the choices are going to be interpreted was presented
ahead of time, was available throughout the entire discussion period, and
very clearly so:
"In case the majority chooses to extend the lifetime of PHP 5.6 (>50%) -
then the option garnering more votes between the two proposed timelines
would win."

I'm not sure what the situation would have been had we truly had a 23/23
split, probably a revote or an extended voting period, but the current
situation is very well defined under the RFC terms.

Not that I particularly care about this outcome, but there were only
"42" Yes votes, and "2" No votes. As the voting says for the second part
"ONLY IF YOU CHOSE 'YES' ABOVE: ", there should only be 42 votes in the
second part, and not 44 like there are now (21+23)... so there is
something wonky.

"There were two voters who didn't vote "yes" for the first poll who voted on
the second poll, but as they chose different options the conclusion doesn't
change."

I would recommend, not to do split votes like this anymore. It's just
too confusing IMO.

I don't think we can avoid some confusion, we could have had a three way
vote here (keep the current, expand #1, expand #2) but then people would
argue that the tho expand options should win in sum or one of those
separately. We could have delayed the second vote after the first one, but
then it could be argued that somebody would have voted differently if they
knew the options for the second vote (or even the progress of the votes)
beforehand. Or Zeev could have picked one of the two dates, and seeing the
results it is entirely possible that the vote would have failed regardless
of the date picked (assuming that the No voters would have voted no
anyways, and some of the yes voters would have voted no because of their
disagreement with the proposed date) which seems to be a bad outcome seeing
how the yes-no vote went to 42:2.
So I don't think we had a objectively better alternative or how could
always have the best outcome with a simple vote of two options.

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

9 years ago by Joe Watkins — view source — reply

unread

The way the RFC the choices are going to be interpreted was presented
ahead of time, was available throughout the entire discussion period, and
very clearly so:

So what !?

The terms are clearly biased towards the longest support period if "no, I
don't want to extend support period" is going to be taken to mean "yes,
extend the support period using the longest option" ...

Whatever, the options don't make sense ...

Cheers
Joe

-----Original Message-----
From: Bob Weinand [mailto:bobwei9@hotmail.com]
Sent: Wednesday, January 13, 2016 3:16 PM
To: Zeev Suraski zeev@zend.com
Cc: Joe Watkins pthreads@pthreads.org; PHP internals
internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] [VOTE] PHP 5's Support Timeline

I agree,

no votes should be meaning "I want as less as possible support".
Counting it that way would make it up for a tie and us choosing the most
restrictive schedule as a result.
(Interpreting it like "you need 50%+1 of the total to get it extended so
far".)

Hence Security Support until Dec 31 2017.

Bob,

The way the RFC the choices are going to be interpreted was presented
ahead of time, was available throughout the entire discussion period, and
very clearly so:
"In case the majority chooses to extend the lifetime of PHP 5.6 (>50%) -
then the option garnering more votes between the two proposed timelines
would win."

I'm not sure what the situation would have been had we truly had a 23/23
split, probably a revote or an extended voting period, but the current
situation is very well defined under the RFC terms.

Thanks,

Zeev

9 years ago by Ferenc Kovacs — view source — reply

unread

The way the RFC the choices are going to be interpreted was presented
ahead of time, was available throughout the entire discussion period, and
very clearly so:

So what !?

so this should have been brought up before the voting was closed or even
before it was started.
otherwise these late complaints can be used for vote manipulation: wait for
the votes and bring up the problem when the result did not went the way the
reporter wanted.
ofc. I'm not suggesting that you have intentionally held back this
complain, just explaining why it is much harder to do anything with it
based on the fact that this was articulated in the rfc explicitly and
nobody complained about it before the votes were closed.

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

9 years ago by me@rouvenwessling.de — view source — reply

unread

I don't think we can avoid some confusion, we could have had a three way
vote here (keep the current, expand #1, expand #2) but then people would
argue that the tho expand options should win in sum or one of those
separately. We could have delayed the second vote after the first one, but
then it could be argued that somebody would have voted differently if they
knew the options for the second vote (or even the progress of the votes)
beforehand. Or Zeev could have picked one of the two dates, and seeing the
results it is entirely possible that the vote would have failed regardless
of the date picked (assuming that the No voters would have voted no
anyways, and some of the yes voters would have voted no because of their
disagreement with the proposed date) which seems to be a bad outcome seeing
how the yes-no vote went to 42:2.
So I don't think we had a objectively better alternative or how could
always have the best outcome with a simple vote of two options.

I don’t have voting rights but I don’t think there is a problem with multiple votes in one RFC,
even if they are chained (b only matters if a passes). What doesn't make sense is for the voting
right to be restricted based on how one voted (may only vote in b if voted for a with option X).

Of course most people would make the most restrictive choice in the second vote if they were
against the whole RFC, but that would make it an effective reflection on how everyone feel.

Best regards
Rouven

9 years ago by Larry Garfield — view source — reply

unread

I don't think we can avoid some confusion, we could have had a three way
vote here (keep the current, expand #1, expand #2) but then people would
argue that the tho expand options should win in sum or one of those
separately. We could have delayed the second vote after the first one, but
then it could be argued that somebody would have voted differently if they
knew the options for the second vote (or even the progress of the votes)
beforehand. Or Zeev could have picked one of the two dates, and seeing the
results it is entirely possible that the vote would have failed regardless
of the date picked (assuming that the No voters would have voted no
anyways, and some of the yes voters would have voted no because of their
disagreement with the proposed date) which seems to be a bad outcome seeing
how the yes-no vote went to 42:2.
So I don't think we had a objectively better alternative or how could
always have the best outcome with a simple vote of two options.
I don’t have voting rights but I don’t think there is a problem with multiple votes in one RFC,
even if they are chained (b only matters if a passes). What doesn't make sense is for the voting
right to be restricted based on how one voted (may only vote in b if voted for a with option X).

Of course most people would make the most restrictive choice in the second vote if they were
against the whole RFC, but that would make it an effective reflection on how everyone feel.

Best regards
Rouven

That is essentially what IRV allows: First choice is A, but if A doesn't
pass my next choice is B, and if that doesn't pass my next choice is C.
At this point, I'm of the mind that any non-binary vote should use IRV.

IRV: https://en.wikipedia.org/wiki/Instant-runoff_voting

--
--Larry Garfield

9 years ago by Pierre Joye — view source — reply

unread

The way the RFC the choices are going to be interpreted was presented
ahead of time, was available throughout the entire discussion period, and
very clearly so:

So what !?

The terms are clearly biased towards the longest support period if "no, I
don't want to extend support period" is going to be taken to mean "yes,
extend the support period using the longest option" ...

Whatever, the options don't make sense ...

Why I change my vote from no to extend to yes and take the shorter options.

It would have been better to have all options clearly exposed.

Cheers
Joe

-----Original Message-----
From: Bob Weinand [mailto:bobwei9@hotmail.com]
Sent: Wednesday, January 13, 2016 3:16 PM
To: Zeev Suraski zeev@zend.com
Cc: Joe Watkins pthreads@pthreads.org; PHP internals
internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] [VOTE] PHP 5's Support Timeline

I agree,

no votes should be meaning "I want as less as possible support".
Counting it that way would make it up for a tie and us choosing the
most
restrictive schedule as a result.
(Interpreting it like "you need 50%+1 of the total to get it extended
so
far".)

Hence Security Support until Dec 31 2017.

Bob,

The way the RFC the choices are going to be interpreted was presented
ahead of time, was available throughout the entire discussion period,
and
very clearly so:
"In case the majority chooses to extend the lifetime of PHP 5.6 (>50%) -
then the option garnering more votes between the two proposed timelines
would win."

I'm not sure what the situation would have been had we truly had a 23/23
split, probably a revote or an extended voting period, but the current
situation is very well defined under the RFC terms.

Thanks,

Zeev