On Tue, 2013-01-08 at 12:39 +0100, Pierre Joye wrote: > On Tue, Jan 8, 2013 at 12:25 PM, Clint Priest <cpri...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
