Re: [PHP-DEV] Re: [RFC] Abolish 50%+1 Votes

[Yasuo Ohgaki]

Hi Joe,

On Fri, Nov 18, 2016 at 2:53 AM, Joe Watkins  wrote:
>
> https://wiki.php.net/rfc/abolish-narrow-margins

Requiring 2/3 majority is reasonable.

I'll vote yes for this if people who are not in favor disclose the
reason why. Just voting "no" for a RFC is not constructive. Improving
a RFC is difficult without reason why it is not preferred. Decision
could be based on wrong assumption and/or misunderstanding sometimes.

Could we have comment plugin for this? It does not have be to a
comment plugin, if there is better plugin for the purpose.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] Abolish 50%+1 Votes

[Christoph M. Becker]

On 18.11.2016 at 12:05, Yasuo Ohgaki wrote:

> On Fri, Nov 18, 2016 at 2:53 AM, Joe Watkins  wrote:
>>
>> https://wiki.php.net/rfc/abolish-narrow-margins
> 
> Requiring 2/3 majority is reasonable.
> 
> I'll vote yes for this if people who are not in favor disclose the
> reason why. Just voting "no" for a RFC is not constructive. Improving
> a RFC is difficult without reason why it is not preferred. Decision
> could be based on wrong assumption and/or misunderstanding sometimes.
> 
> Could we have comment plugin for this? It does not have be to a
> comment plugin, if there is better plugin for the purpose.

We may consider to customize the doodle plugin[1]. IIRC, it is
alread customized and the original is unmaintained, so there
won't be update issues.

[1]


-- 
Christoph M. Becker


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: VCS Account Request: sven

[PHP Group]

VCS Account Approved: sven approved by cmb \o/


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Introduction

[Tobias Nyholm]

Hey.
I’m nyholm.
I want to update the Google Summer of code page on the wiki to be more
accurate.
https://wiki.php.net/gsoc



Regards
Tobias Nyholm

[PHP-DEV] Re: VCS Account Request: emir

[PHP Group]

VCS Account Approved: emir approved by cmb \o/


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: VCS Account Request: emir

[Peter Cowburn]

On 18 November 2016 at 14:33, PHP Group  wrote:

> VCS Account Approved: emir approved by cmb \o/
>
>
Why? We don't even know what karma he's going to need. There's very little
point in having an account without that.


>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

[PHP-DEV] [RFC] Deprecations for PHP 7.2

[Nikita Popov]

Hi internals!

I've submitted this RFC for PHP 7.1 previously, but didn't follow through
due to time constraints. Now I'd like to propose an extended version for
PHP 7.2 and vote on it sooner rather than later to avoid a repeat
performance.

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

The RFC combines a number of deprecation and removal proposals. Each one
will get a separate 2/3 majority vote. The RFC overlaps with some recently
discussed topics (each, binary strings) -- I'm fine with dropping these if
someone has a more specific RFC.

I expect some of these are no-brainers, while others are more controversial
-- please share your specific concerns.

Thanks,
Nikita

Re: [PHP-DEV] Re: VCS Account Request: emir

[Christoph M. Becker]

On 18.11.2016 at 15:39, Peter Cowburn wrote:

> On 18 November 2016 at 14:33, PHP Group  wrote:
> 
>> VCS Account Approved: emir approved by cmb \o/
>
> Why? We don't even know what karma he's going to need. There's very little
> point in having an account without that.

Well, you're right (again :-).  What now?

Cheers,
Christoph

>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
> 


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] Abolish 50%+1 Votes

[Joe Watkins]

Afternoon Yasuo,

Maybe, it is our fault - the person who created the RFC.

In an ideal world, during discussion you should collect legitimate
unresolved objections, and have those as "no" options on the vote.

If when it came to vote time, the options were:

Yes
No because X
No because Y
No because Z
No

I think most people would be happy to provide a reason, if you have it
listed.
It should be listed, because it should have been brought up during
discussion.

Obviously we don't live in an ideal world, and you may get lots of no votes
still that don't provide a reason.

But it doesn't need to be ideal to give us some clue of where to take the
RFC next.

Many people don't like the idea of requiring a reason, but I'm sure the
same people would provide one if it were listed as a voting option. What
they don't want is to have to constantly defend their decision after it's
been made, which is in some sense reasonable.

Cheers
Joe

On Fri, Nov 18, 2016 at 11:05 AM, Yasuo Ohgaki  wrote:

> Hi Joe,
>
> On Fri, Nov 18, 2016 at 2:53 AM, Joe Watkins 
> wrote:
> >
> > https://wiki.php.net/rfc/abolish-narrow-margins
>
> Requiring 2/3 majority is reasonable.
>
> I'll vote yes for this if people who are not in favor disclose the
> reason why. Just voting "no" for a RFC is not constructive. Improving
> a RFC is difficult without reason why it is not preferred. Decision
> could be based on wrong assumption and/or misunderstanding sometimes.
>
> Could we have comment plugin for this? It does not have be to a
> comment plugin, if there is better plugin for the purpose.
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
>

[PHP-DEV] Request for php-src karma

[Taoguang Chen]

I'm requesting php-src karma and security karma (r...@php.net 
), and I’m gladly willing to help with some security 
issues. I had already submitted a lot of security issues in past.

https://bugs.php.net/search.php?search_for=&boolean=0&limit=All&order_by=&direction=DESC&cmd=display&status=All&bug_type=All&project=All&php_os=&phpver=&cve_id=&assign=&author_email=taoguangchen%40icloud.com&bug_age=0&bug_updated=0
 

[PHP-DEV] Declare directive to change engine version basis

[David Rodrigues]

Hello.

I like to propose a creation of a new declare() directive that allows
"emulates a future engine version". And where I say engine I mean PHP
itself.

-

It should works like it (eg. for engine version "7.0.13"):

declare( {{parameter}} = {{php_version_id}} );

// Examples (one of that):
declare( engine_version = 70013 ); // or
declare( php_version = 70013 );

-

By default, this declaration is not defined (null or 0), then will not
do anything to engine if it's not declared on script.

-

This declaration could be done at:

- First execution file.php (bootstrap): then all application will
follow this engine rules;
- Any file.php: then only current file will follow this rules (to
override locally first declaration);
- php.ini: to set this declaration as default to all applications
(optional);

-

What it does: in pratical, if the engine will deprecated or change
something on future versions (mainly causing BCs), you should wait for
a new major version (eg. 7.x -> 8.x). With this declaration you could
emulates a future version to prepares your scripts to a new major
version.

-

Let working on an example from: https://wiki.php.net/rfc/deprecations_php_7_2

The (unset) cast should not be used anymore because it's have not any
effect (just return null, but not affect the expression or variable).
Let supposed that this deprecation is done at 7.2.0 (id 70200), then
if I'm using this version and I declare engine_version like:

- no declared or null: just a deprecation notice;
- declare as 70200 or higher: error, (unset) cast doesn't exists
(or something like that)

-

Then, what the engine_version does is set some variable to engine that
could check if it could be executed on declared version, then
developers can code their files to future versions without need wait
for it.

-

If the installed version is different of declared version, then the
engine will always consider the lowest version between both. For
instance: if installed version is 70201 (7.2.1) and declared version
is 70205 (7.2.5), then engine will consider changes from 70201 (7.2.1,
once that installed is lower). And again: engine will works
differently only if declaration is done, else, it'll works by
deprecation notice, for instance.

-

What happen on engine code is something like that (pseudo-code):

int engine_version () {
return (int) engine_version_declaration;
}

cast type unset () {
if (engine_version() >= 70201) {
fatal(cast doesn't supported);
}

notice(deprecated);
return null;
}


-- 
David Rodrigues

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [RFC] Deprecations for PHP 7.2

[Christoph M. Becker]

On 18.11.2016 at 15:55, Nikita Popov wrote:
> Hi internals!
> 
> I've submitted this RFC for PHP 7.1 previously, but didn't follow through
> due to time constraints. Now I'd like to propose an extended version for
> PHP 7.2 and vote on it sooner rather than later to avoid a repeat
> performance.
> 
> https://wiki.php.net/rfc/deprecations_php_7_2
> 
> The RFC combines a number of deprecation and removal proposals. Each one
> will get a separate 2/3 majority vote. The RFC overlaps with some recently
> discussed topics (each, binary strings) -- I'm fine with dropping these if
> someone has a more specific RFC.
> 
> I expect some of these are no-brainers, while others are more controversial
> -- please share your specific concerns.

Thanks, Nikita!  I'm generally in favor of such clean up.

The only exception would be features which have only been available as
of PHP 7, currently only assertion expressions.  Deprecating assertion
strings as of PHP 7.2 would make it hard to provide PHP 5.6 and PHP 7.2
compatible code, even though 7.2 GA is supposed to be released in
December 2017, whereas there'll be security support for 5.6 until end of
2018[1].

[1] 

-- 
Christoph M. Becker


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Declare directive to change engine version basis

[Daniel Morris]

I think this would create a lot of additional work for internals
maintainers, and the current system of throwing an E_DEPRECATED already
allows for developers to prepare their applications for future versions
by turning on error reporting and checking their logs.

--
Daniel Morris
dan...@honestempire.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Declare directive to change engine version basis

[Stephen Reay]

Hi David,

If you wanted to do this, couldn’t you simply use the following, already:

set_error_handler(
function (int $err_severity, string $err_msg, string $err_file, int 
$err_line, array $err_context) {
throw new ErrorException($err_msg, 0, $err_severity, $err_file, 
$err_line)
},
E_DEPRECATED
);

?

> On 18 Nov 2016, at 23:18, David Rodrigues  wrote:
> 
> Hello.
> 
> I like to propose a creation of a new declare() directive that allows
> "emulates a future engine version". And where I say engine I mean PHP
> itself.
> 
> -
> 
> It should works like it (eg. for engine version "7.0.13"):
> 
>declare( {{parameter}} = {{php_version_id}} );
> 
>// Examples (one of that):
>declare( engine_version = 70013 ); // or
>declare( php_version = 70013 );
> 
> -
> 
> By default, this declaration is not defined (null or 0), then will not
> do anything to engine if it's not declared on script.
> 
> -
> 
> This declaration could be done at:
> 
>- First execution file.php (bootstrap): then all application will
> follow this engine rules;
>- Any file.php: then only current file will follow this rules (to
> override locally first declaration);
>- php.ini: to set this declaration as default to all applications
> (optional);
> 
> -
> 
> What it does: in pratical, if the engine will deprecated or change
> something on future versions (mainly causing BCs), you should wait for
> a new major version (eg. 7.x -> 8.x). With this declaration you could
> emulates a future version to prepares your scripts to a new major
> version.
> 
> -
> 
> Let working on an example from: https://wiki.php.net/rfc/deprecations_php_7_2
> 
> The (unset) cast should not be used anymore because it's have not any
> effect (just return null, but not affect the expression or variable).
> Let supposed that this deprecation is done at 7.2.0 (id 70200), then
> if I'm using this version and I declare engine_version like:
> 
>- no declared or null: just a deprecation notice;
>- declare as 70200 or higher: error, (unset) cast doesn't exists
> (or something like that)
> 
> -
> 
> Then, what the engine_version does is set some variable to engine that
> could check if it could be executed on declared version, then
> developers can code their files to future versions without need wait
> for it.
> 
> -
> 
> If the installed version is different of declared version, then the
> engine will always consider the lowest version between both. For
> instance: if installed version is 70201 (7.2.1) and declared version
> is 70205 (7.2.5), then engine will consider changes from 70201 (7.2.1,
> once that installed is lower). And again: engine will works
> differently only if declaration is done, else, it'll works by
> deprecation notice, for instance.
> 
> -
> 
> What happen on engine code is something like that (pseudo-code):
> 
>int engine_version () {
>return (int) engine_version_declaration;
>}
> 
>cast type unset () {
>if (engine_version() >= 70201) {
>fatal(cast doesn't supported);
>}
> 
>notice(deprecated);
>return null;
>}
> 
> 
> -- 
> David Rodrigues
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
> 


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: VCS Account Request: mgage

[Christoph M. Becker]

On 20.06.2015 at 04:58, Gage Morgan wrote:

> Alexandre (buhlerax) and I are going to rewrite PHP-GTK from scratch.
> In order for me to do my part, I will need to be able to access the
> Git repository. I am currently active in the php-gtk-dev mailing
> list.

Is that request still relevant?  If so, which karma would you need?

-- 
Christoph M. Becker


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: VCS Account Request: fp

[Christoph M. Becker]

On 08.09.2016 at 15:57, Legai Yuri wrote:

> Join to php development group

Did you already contribute to the project (patches, pull requests, etc.)?

-- 
Christoph M. Becker


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: VCS Account Request: profforg

[Christoph M. Becker]

On 27.05.2015 at 06:10, Alexander Loginov wrote:

> Hello.
> 
> I am Linux System Administrator since 2007. Working with php every
> day. I think i actively working with php since 2008. I wanted to help
> php in some way for a long time. Time goes and seems to be a good to
> idea to start, at least. I doubt that my C skills will be enough to
> write something important for php source; probably minor pull
> requests only. Also probably i can remember some documentation and
> documentation translation wierds i seen. Hopefully i can help on
> other php parts, wiki, bugs.

You don't necessarily need a VCS account to do so.  For instance, you
can submit pull requests to one or more of the respective Git repos, or
you can submit documentation/translation patches via
.

-- 
Christoph M. Becker


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Request for php-src karma

[Kalle Sommer Nielsen]

2016-11-18 16:33 GMT+01:00 Taoguang Chen :
> I'm requesting php-src karma and security karma (r...@php.net 
> ), and I’m gladly willing to help with some security 
> issues. I had already submitted a lot of security issues in past.
>
> https://bugs.php.net/search.php?search_for=&boolean=0&limit=All&order_by=&direction=DESC&cmd=display&status=All&bug_type=All&project=All&php_os=&phpver=&cve_id=&assign=&author_email=taoguangchen%40icloud.com&bug_age=0&bug_updated=0
>  
> 

ccing stas for this, as he is the main go to guy for this (and the one
that seems to have been assigned to most of the issues you have
reported)

-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Deprecations for PHP 7.2

[Kalle Sommer Nielsen]

Hi Nikita

2016-11-18 15:55 GMT+01:00 Nikita Popov :
> Hi internals!
>
> I've submitted this RFC for PHP 7.1 previously, but didn't follow through
> due to time constraints. Now I'd like to propose an extended version for
> PHP 7.2 and vote on it sooner rather than later to avoid a repeat
> performance.
>
> https://wiki.php.net/rfc/deprecations_php_7_2
>
> The RFC combines a number of deprecation and removal proposals. Each one
> will get a separate 2/3 majority vote. The RFC overlaps with some recently
> discussed topics (each, binary strings) -- I'm fine with dropping these if
> someone has a more specific RFC.
>
> I expect some of these are no-brainers, while others are more controversial
> -- please share your specific concerns.

Awesome list, thanks for your work. I got a couple of things to maybe
consider adding:

arg_separator.output/input -- Do we really need an ini to define
these, can't they be baked in or something? (I did not look at the
code)
auto_prepend/auto_append_file directives, I would be amazed if there
couldn't be some optimization complications with those too
register_argv_argc -- deprecate for non CLI?

Might have other things to add later on, these are just what I had in
mind so far


-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [RFC][Accepted] Security Issue Classification

[Stanislav Malyshev]

Hi!

> Pleased to announce that the vote for security issue classification is
> closed, and passed unanimously.
> 

Thank you for taking care of it!

-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [RFC] Deprecations for PHP 7.2

[Jan Ehrhardt]

Nikita Popov in php.internals (Fri, 18 Nov 2016 15:55:23 +0100):
>https://wiki.php.net/rfc/deprecations_php_7_2
>
>The RFC combines a number of deprecation and removal proposals. Each one
>will get a separate 2/3 majority vote. The RFC overlaps with some recently
>discussed topics (each, binary strings)

I must have missed the discussion about each(). And this really
surprised me:

> The each() function is inferior to foreach in pretty much every
> imaginable way, including being more than 10 times slower.

But it is mentioned in a 9-year old comment in the manual:
https://php.net/manual/en/function.each.php#75692

A quick grep in my Drupal7 source code showed that not everybody is
aware of that. For instance, even the views module use a list() = each()
construction:
http://cgit.drupalcode.org/views/tree/includes/view.inc#n1740
This means that at least 800,000 sites use list() = each() at the
moment.

I am fine with deprecation, but this may be more wide spread than one
might assume.
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Deprecations for PHP 7.2

[Christoph M. Becker]

On 18.11.2016 at 20:01, Kalle Sommer Nielsen wrote:

> 2016-11-18 15:55 GMT+01:00 Nikita Popov :
>
>> I've submitted this RFC for PHP 7.1 previously, but didn't follow through
>> due to time constraints. Now I'd like to propose an extended version for
>> PHP 7.2 and vote on it sooner rather than later to avoid a repeat
>> performance.
>>
>> https://wiki.php.net/rfc/deprecations_php_7_2
>>
>> The RFC combines a number of deprecation and removal proposals. Each one
>> will get a separate 2/3 majority vote. The RFC overlaps with some recently
>> discussed topics (each, binary strings) -- I'm fine with dropping these if
>> someone has a more specific RFC.
>>
>> I expect some of these are no-brainers, while others are more controversial
>> -- please share your specific concerns.
> 
> Awesome list, thanks for your work. I got a couple of things to maybe
> consider adding:
> 
> arg_separator.output/input -- Do we really need an ini to define
> these, can't they be baked in or something? (I did not look at the
> code)

See also a recent discussion on comp.lang.php:
.

TL;DR: these ini settings may cause quite some confusion (note that the
OP is a long-term PHP developer), but removing them might cause
considerable BC breakage.  We have to be very careful here, IMHO.

-- 
Christoph M. Becker


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC DISCUSSION] User defined session serializer

[Markus Fischer]

Hello,

On 17.11.2016 11:55, Yasuo Ohgaki wrote:
> 
> Session module implements serialize handler as module.
> This RFC is to expose it to user space.
> 
> RFC
> https://wiki.php.net/rfc/user_defined_session_serializer
> 
> PR
> https://github.com/php/php-src/pull/2205
> 
> Comments are appreciated!

Well, I like it. It's sometimes necessary to share session state with
non-PHP application and this is IMHO a welcome addition to ease the
exchange.

Btw, what is the proper way to signal a problem during
serialization/unserialization? I couldn't figure it out from the RFC nor
the PR and there doesn't seem to be a test case for it.
Return null/false? Throw an exception?

thanks,
- Markus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Deprecations for PHP 7.2

[Yasuo Ohgaki]

Hi all,

On Sat, Nov 19, 2016 at 4:01 AM, Kalle Sommer Nielsen  wrote:
> auto_prepend/auto_append_file directives

auto_prepend/append_file is handy to check application
performance/statistical information such as memory usage while
development and/or testing, for example. Do these harm any other than
shooting their own foot?

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Deprecations for PHP 7.2

[Kalle Sommer Nielsen]

2016-11-19 1:05 GMT+01:00 Yasuo Ohgaki :
> Hi all,
>
> On Sat, Nov 19, 2016 at 4:01 AM, Kalle Sommer Nielsen  wrote:
>> auto_prepend/auto_append_file directives
>
> auto_prepend/append_file is handy to check application
> performance/statistical information such as memory usage while
> development and/or testing, for example. Do these harm any other than
> shooting their own foot?
>

Maybe not so much, but I'd like to hear any impact they could have on
optimization much like some of the features in the RFC is mentioned to
be problematic. I did used to use those directives for similar things,
but it was a decade ago :/

-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] Abolish 50%+1 Votes

[Yasuo Ohgaki]

Hi Joe,

On Sat, Nov 19, 2016 at 12:28 AM, Joe Watkins  wrote:
> I think most people would be happy to provide a reason, if you have it
> listed.
> It should be listed, because it should have been brought up during
> discussion.
>
> Obviously we don't live in an ideal world, and you may get lots of no votes
> still that don't provide a reason.

There are clear cases that people misunderstand proposals.

Recent example is PRNG adoption for uniqid(). I proposed patch does
not have any BC, but there were people opposed based on false FUD.
i.e. RPNG device access causes  access error which is _nothing_ to do
with internal function.

Another example is session ID validation. It is mandatory to keep
session as secure as possible, yet there are some people do not
realize(?) why it is mandatory. There is workaround, but I haven't
seen implementation does it correctly. I would rather just fix the
issue rather than trying to teach how to do it.

Anyway, regardless of opposition is reasonable or not, disclosing the
reason why it is not preferred is valuable. Could you at least state
in the RFC that all voters who are not in favor of the proposal should
disclose the reason?

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Abolish 50%+1 Votes

[Pierre Joye]

Good afternoon,

On Nov 18, 2016 12:18 AM, "Joe Watkins"  wrote:

>
> There will be a one week discussion period for this RFC.

Sorry but the minimum discussion period for RFC is two weeks. No exception.

I will reply later for the feedback on the RFC :)

Cheers
Pierre

Re: [PHP-DEV] Re: [RFC] Abolish 50%+1 Votes

[Marcio Almada]

2016-11-18 22:10 GMT-04:00 Yasuo Ohgaki :

> Hi Joe,
>
> On Sat, Nov 19, 2016 at 12:28 AM, Joe Watkins 
> wrote:
> > I think most people would be happy to provide a reason, if you have it
> > listed.
> > It should be listed, because it should have been brought up during
> > discussion.
> >
> > Obviously we don't live in an ideal world, and you may get lots of no
> votes
> > still that don't provide a reason.
>
> There are clear cases that people misunderstand proposals.
>
> Recent example is PRNG adoption for uniqid(). I proposed patch does
> not have any BC, but there were people opposed based on false FUD.
> i.e. RPNG device access causes  access error which is _nothing_ to do
> with internal function.
>
> Another example is session ID validation. It is mandatory to keep
> session as secure as possible, yet there are some people do not
> realize(?) why it is mandatory. There is workaround, but I haven't
> seen implementation does it correctly. I would rather just fix the
> issue rather than trying to teach how to do it.
>
> Anyway, regardless of opposition is reasonable or not, disclosing the
> reason why it is not preferred is valuable. Could you at least state
> in the RFC that all voters who are not in favor of the proposal should
> disclose the reason?
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>


Hi Yasuo,

In my opinion, this belongs to another RFC. Please, propose an optional way
for voters to input a small paragraph disclosing a justification upon
voting. We've seen many voices on this mailing list supporting this
proposal, perhaps it's time to discuss officially. Keep in mind this change
in the voting process requires the voting doodle to be customized somehow
(I don't know how).

Best regards,
Márcio.

Re: [PHP-DEV] Re: [RFC] Abolish 50%+1 Votes

[Alice Wonder]

On 11/18/2016 06:26 PM, Marcio Almada wrote:



Hi Yasuo,

In my opinion, this belongs to another RFC. Please, propose an optional way
for voters to input a small paragraph disclosing a justification upon
voting. We've seen many voices on this mailing list supporting this
proposal, perhaps it's time to discuss officially. Keep in mind this change
in the voting process requires the voting doodle to be customized somehow
(I don't know how).

Best regards,
Márcio.



Explaining why someone votes against something makes voting against more 
difficult than voting for.


I would suggest just increasing the margin to pass. That's a good way to 
solve the issue, and the pros and cons can be discussed on the list.


Is it required to be a member of this list to vote? That too would be a 
good idea if it isn't required, hopefully translators are accurate 
enough to understand arguments here pro and con when not in a language 
the voter has excellent grasp of.


Personally I abstain from voting because I do not feel qualified to make 
decisions that impact the majority of PHP users, but some things I may 
comment on, but only on this list.



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] Abolish 50%+1 Votes

[Kalle Sommer Nielsen]

2016-11-19 3:39 GMT+01:00 Alice Wonder :
> Is it required to be a member of this list to vote? That too would be a good
> idea if it isn't required, hopefully translators are accurate enough to
> understand arguments here pro and con when not in a language the voter has
> excellent grasp of.

Only people with active VCS accounts or wiki accounts (that's been
approved) are allowed to vote.



-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] Abolish 50%+1 Votes

[Alice Wonder]

On 11/18/2016 06:55 PM, Kalle Sommer Nielsen wrote:

2016-11-19 3:39 GMT+01:00 Alice Wonder :

Is it required to be a member of this list to vote? That too would be a good
idea if it isn't required, hopefully translators are accurate enough to
understand arguments here pro and con when not in a language the voter has
excellent grasp of.


Only people with active VCS accounts or wiki accounts (that's been
approved) are allowed to vote.





Thank you, I knew there was an identity validation requirement, and that 
makes sense.


I do know I enjoy reading the RFC discussions here on what is proposed 
to be deprecated, it often has helped me realize there is a better way 
to do something than the way I currently am doing something.


mcrypt for example, after reading about how stale it was, I didn't wait 
to deprecate it on my own but just removed it from my php build - and 
any web apps I install that want it, I fix.


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Abolish 50%+1 Votes

[Joe Watkins]

Morning Pierre,

That's not what the rules say.

There will be a one week discussion period.

Cheers
Joe

On 19 Nov 2016 2:20 a.m., "Pierre Joye"  wrote:

> Good afternoon,
>
> On Nov 18, 2016 12:18 AM, "Joe Watkins"  wrote:
>
> >
> > There will be a one week discussion period for this RFC.
>
> Sorry but the minimum discussion period for RFC is two weeks. No exception.
>
> I will reply later for the feedback on the RFC :)
>
> Cheers
> Pierre
>

Re: [PHP-DEV] [RFC DISCUSSION] User defined session serializer

[Yasuo Ohgaki]

Hi Markus,

On Sat, Nov 19, 2016 at 9:02 AM, Markus Fischer  wrote:
> On 17.11.2016 11:55, Yasuo Ohgaki wrote:
>>
>> Session module implements serialize handler as module.
>> This RFC is to expose it to user space.
>>
>> RFC
>> https://wiki.php.net/rfc/user_defined_session_serializer
>>
>> PR
>> https://github.com/php/php-src/pull/2205
>>
>> Comments are appreciated!
>
> Well, I like it. It's sometimes necessary to share session state with
> non-PHP application and this is IMHO a welcome addition to ease the
> exchange.
>
> Btw, what is the proper way to signal a problem during
> serialization/unserialization? I couldn't figure it out from the RFC nor
> the PR and there doesn't seem to be a test case for it.
> Return null/false? Throw an exception?

It raises E_RECOVERABLE_ERROR currently. I choose it because session
module raises errors.  However, I prefer to use exception over error.
I'll create a RFC to adopt exception for session.

Thank you for feedback about tests, I'll add error case tests.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Abolish 50%+1 Votes

[Levi Morrison]

On Fri, Nov 18, 2016 at 9:11 PM, Joe Watkins  wrote:
> Morning Pierre,
>
> That's not what the rules say.
>
> There will be a one week discussion period.
>
> Cheers
> Joe
>
> On 19 Nov 2016 2:20 a.m., "Pierre Joye"  wrote:
>
>> Good afternoon,
>>
>> On Nov 18, 2016 12:18 AM, "Joe Watkins"  wrote:
>>
>> >
>> > There will be a one week discussion period for this RFC.
>>
>> Sorry but the minimum discussion period for RFC is two weeks. No exception.
>>
>> I will reply later for the feedback on the RFC :)
>>
>> Cheers
>> Pierre
>>

See https://wiki.php.net/rfc/howto; it does say two weeks minimum in
step 6. If you know of anywhere it says one week please let me know.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Abolish 50%+1 Votes

[Pierre Joye]

On Nov 19, 2016 11:11 AM, "Joe Watkins"  wrote:
>
> Morning Pierre,
>
> That's not what the rules say.
>
> There will be a one week discussion period.

Sorry but no.

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

Re: [PHP-DEV] [RFC] Abolish 50%+1 Votes

[Joe Watkins]

Morning Pierre,

Sorry, but yes.

http://wiki.php.net/rfc/voting

> There'd be a minimum of 2 weeks between when an RFC that touches the
language is brought up on this list and when it's voted on is required.
Other RFCs might use a smaller timeframe, but it should be at least a week.

Cheers
Joe

On Sat, Nov 19, 2016 at 4:28 AM, Pierre Joye  wrote:

> On Nov 19, 2016 11:11 AM, "Joe Watkins"  wrote:
> >
> > Morning Pierre,
> >
> > That's not what the rules say.
> >
> > There will be a one week discussion period.
>
> Sorry but no.
>
> https://wiki.php.net/rfc/howto
>