Everything

php

[RFC][discussion] 5.3 EOL

php.internals

Pierre Joye

13 years ago

hi,

While the 5.3 RM already unilaterally published some announce about
5.3 status with the last release, we still have to clearly and openly
decide what is the best road to take.

Here is the last version of the rfc:

https://wiki.php.net/rfc/php53eol

If anyone has any other additional options to add, please raise your
voice. I plan to go for the votes tonight.

ps: pls do not hijack this post to ask to do not end support at all or
any other unrelated topic, refer to the numerous previous threads if
you need to refresh your mind, thanks for your understanding.

Cheers,

--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

Kris Craig

13 years ago

On Tue, Jan 8, 2013 at 1:36 AM, Pierre Joye <pierre.php@gmail.com> wrote:

> hi,
>
> While the 5.3 RM already unilaterally published some announce about
> 5.3 status with the last release, we still have to clearly and openly
> decide what is the best road to take.
>
> Here is the last version of the rfc:
>
> https://wiki.php.net/rfc/php53eol
>
> If anyone has any other additional options to add, please raise your
> voice. I plan to go for the votes tonight.
>
> ps: pls do not hijack this post to ask to do not end support at all or
> any other unrelated topic, refer to the numerous previous threads if
> you need to refresh your mind, thanks for your understanding.
>
> Cheers,
> --
> Pierre
>
> @pierrejoye | http://blog.thepimp.net | http://www.libgd.org
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Would a voting option to tie it to the release of a future PHP version,
rather than a fixed time interval, be appropriate?

--Kris

Pierre Joye

13 years ago

On Tue, Jan 8, 2013 at 10:48 AM, Kris Craig <kris.craig@gmail.com> wrote:

> Would a voting option to tie it to the release of a future PHP version,
> rather than a fixed time interval, be appropriate?

Like in end it when 5.x is released? Not sure it helps in anyway, but
that's possible already if we choose to begin the EOL cycle with the
release of 5.5 (yearly release).

Cheers,

--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

Clint M Priest

13 years ago

Would this 1 or 2 year period begin from release date of 5.3 or as of around now/vote?

-Clint

On Jan 8, 2013, at 4:00 AM, Pierre Joye <pierre.php@gmail.com> wrote:

Pierre Joye

13 years ago

On Tue, Jan 8, 2013 at 12:25 PM, Clint Priest <cpriest@zerocue.com> wrote:

> Would this 1 or 2 year period begin from release date of 5.3 or as of around now/vote?

See "When should start the EOL period and when should it be announced?"

--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

Johannes Schlueter

13 years ago

On Tue, 2013-01-08 at 12:39 +0100, Pierre Joye wrote:

> On Tue, Jan 8, 2013 at 12:25 PM, Clint Priest <cpriest@zerocue.com> wrote:
>
> > Would this 1 or 2 year period begin from release date of 5.3 or as of around now/vote?
>
> See "When should start the EOL period and when should it be announced?"

I don't understand why we have to go through this again, but anyways, if
we do this:


Separating the two questions is "strange" and can lead to unintended
results. They should be combined into one. Example assumption: 50%+1
vote for "One year with security fixes only" but are split between "With
the next PHP 5.3 release" and "Right after the end of this vote"

Whereas 50%-1 vote for "Two years, one normal fixes and one security
fixes only" and "With the PHP 5.5 final release"

Then the winner will be "One year with security fixes only" and "With
the PHP 5.5 final release" which probably wasn't intended by the
majority.



Aside from that: I don't think we need "the PHP Security team" to review
all things, sometimes individual developers can make the choice, too.
And in my opinion this should be more "fluent" where the bar for
"criticalness" is set higher and higher, instead of suddenly basically
stopping.



In the end we have to deal with two things: On the one side we have
users, they want a stable platform, they can rely on, without functional
changes. Many people I talk to don't care much about small bugs with
easy workarounds, but they care for simple risk-free updates for
security things (which btw. is a reason why many use distribution
packages not php.net's)

On the other side are developers, who nowadays have to test 4 branches
for each essentially trivial fix. This makes the process to verify a
patch more annoying than it should be. Given that most here are
volunteers the barrier shouldn't be set too high.

By reducing the pressure to merge everything, in my opinion, we serve
both - users have less risk updating (yes, with 5.3.18 and 5.3.19 we
changed the behavior slightly, users have to always test this) and
maintainers are a bit freer in their work.


But we've been through this and the both of us won't come to agreement.

johannes

Pierre Joye

13 years ago

On Tue, Jan 8, 2013 at 2:18 PM, Johannes Schlüter
<johannes@schlueters.de> wrote:

> Separating the two questions is "strange" and can lead to unintended
> results. They should be combined into one. Example assumption: 50%+1
> vote for "One year with security fixes only" but are split between "With
> the next PHP 5.3 release" and "Right after the end of this vote"

Not sure to see where is the issue here. One is about how long we want
to support 5.3 and how, and the other is when this phase will begin.

> Whereas 50%-1 vote for "Two years, one normal fixes and one security
> fixes only" and "With the PHP 5.5 final release"
>
> Then the winner will be "One year with security fixes only" and "With
> the PHP 5.5 final release" which probably wasn't intended by the
> majority.

Good point but not sure how to do it without clutter the 1st part... I
thought that 1st choosing which option and then when to begin (that
does not change the 1st option but when one thinks it is a good time
to announce&begin it).

> Aside from that: I don't think we need "the PHP Security team" to review
> all things, sometimes individual developers can make the choice, too.

It is not what it said, but if the security team defines something as
a security issue.

> And in my opinion this should be more "fluent" where the bar for
> "criticalness" is set higher and higher, instead of suddenly basically
> stopping.

Right, common sense applies here. We both know that.

> In the end we have to deal with two things: On the one side we have
> users, they want a stable platform, they can rely on, without functional
> changes. Many people I talk to don't care much about small bugs with
> easy workarounds, but they care for simple risk-free updates for
> security things (which btw. is a reason why many use distribution
> packages not php.net's)

Same here.

> On the other side are developers, who nowadays have to test 4 branches
> for each essentially trivial fix. This makes the process to verify a
> patch more annoying than it should be. Given that most here are
> volunteers the barrier shouldn't be set too high.

If sec only option is chosen, we should not see too many releases but
every 2-3 months.

> But we've been through this and the both of us won't come to agreement.

We do, but we are not alone. I am for one for two years sec only.

Cheers,

--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

Johannes Schlueter

13 years ago

On Tue, 2013-01-08 at 14:25 +0100, Pierre Joye wrote:

> > Whereas 50%-1 vote for "Two years, one normal fixes and one security
> > fixes only" and "With the PHP 5.5 final release"
> >
> > Then the winner will be "One year with security fixes only" and "With
> > the PHP 5.5 final release" which probably wasn't intended by the
> > majority.
>
> Good point but not sure how to do it without clutter the 1st part... I
> thought that 1st choosing which option and then when to begin (that
> does not change the 1st option but when one thinks it is a good time
> to announce&begin it).

One thing is to change from "single vote" to "approval voting" (one can
"aaprove" any of those, sum up, done, one of the best voting systems for
"winner takes it all" things
http://en.wikipedia.org/wiki/Approval_voting) and the other way is to at
least get rid of either "With the next PHP 5.3 release" or "Right after
the end of this vote" if we stick to our about monthly release schedule
that makes a difference of maybe two weeks, which is barely relevant ...

johannes

Pierre Joye

13 years ago

On Tue, Jan 8, 2013 at 2:36 PM, Johannes Schlüter
<johannes@schlueters.de> wrote:

> One thing is to change from "single vote" to "approval voting" (one can
> "aaprove" any of those, sum up, done, one of the best voting systems for
> "winner takes it all" things
> http://en.wikipedia.org/wiki/Approval_voting)

Multiple choices? Don't see the point :)

> and the other way is to at
> least get rid of either "With the next PHP 5.3 release" or "Right after
> the end of this vote" if we stick to our about monthly release schedule
> that makes a difference of maybe two weeks, which is barely relevant ...

good point, done.

--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

Kris Craig

13 years ago

On Tue, Jan 8, 2013 at 2:00 AM, Pierre Joye <pierre.php@gmail.com> wrote:

> On Tue, Jan 8, 2013 at 10:48 AM, Kris Craig <kris.craig@gmail.com> wrote:
>
> > Would a voting option to tie it to the release of a future PHP version,
> > rather than a fixed time interval, be appropriate?
>
>
> Like in end it when 5.x is released?

Actually, I was thinking more like 6.0.  That occurred to me when you
mentioned that it's still the most widely-used branch and that numerous
projects still rely on it.  I'd hypothesize that it's less likely that most
of these folks will bother to upgrade if it's still in the 5.x branch.  I'm
thinking this version-specific cutoff would only apply to security fixes.
I'm not sure if it's a good idea or not, but I figured it was worth
mentioning.  Unless it's just me, it might be worthwhile to add that as a
voting option.

--Kris