Everything

php

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

php.internals

Zeev Suraski

10 years ago

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

Derick Rethans

10 years ago

Hi,

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

cheers,
Derick


On Tue, 5 Jan 2016, Zeev Suraski wrote:

> 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

Pascal MARTIN

10 years ago

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/

Zeev Suraski

10 years ago

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

Joe Watkins

10 years ago

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

On Wed, Jan 13, 2016 at 11:51 AM, Zeev Suraski <zeev@zend.com> wrote:

Bob Weinand

10 years ago

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

Peter Cowburn

10 years ago

On 13 January 2016 at 13:16, Bob Weinand <bobwei9@hotmail.com> wrote:

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

Zeev Suraski

10 years ago

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

Derick Rethans

10 years ago

On Wed, 13 Jan 2016, Zeev Suraski wrote:

> 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

Ferenc Kovacs

10 years ago

On Wed, Jan 13, 2016 at 3:52 PM, Derick Rethans <derick@php.net> wrote:

> On Wed, 13 Jan 2016, Zeev Suraski wrote:
>
> > 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

Joe Watkins

10 years ago

> 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

On Wed, Jan 13, 2016 at 2:05 PM, Zeev Suraski <zeev@zend.com> wrote:

Ferenc Kovacs

10 years ago

On Wed, Jan 13, 2016 at 4:42 PM, Joe Watkins <pthreads@pthreads.org> wrote:

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

Rouven Weßling

10 years ago

> On 13 Jan 2016, at 16:23, Ferenc Kovacs <tyra3l@gmail.com> wrote:
>
> 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

Larry Garfield

10 years ago

On 1/13/16 11:26 AM, Rouven Weßling wrote:

>> On 13 Jan 2016, at 16:23, Ferenc Kovacs <tyra3l@gmail.com> wrote:
>>
>> 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

Pierre Joye

10 years ago

On Jan 13, 2016 10:42 PM, "Joe Watkins" <pthreads@pthreads.org> wrote:

>
> > 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
>
> On Wed, Jan 13, 2016 at 2:05 PM, Zeev Suraski <zeev@zend.com> wrote:
>
> > > -----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