Re: [PHP-DEV] Deprecation of the Error Control Operator (@ symbol)

[Michael Heap]

Sounds like the xdebug.scream or the Scream PECL extension (
https://pecl.php.net/package/scream) to me.

+1 for baking this functionality into core

On Tue, Jan 5, 2016 at 5:45 AM, Sara Golemon  wrote:

> On Thu, Dec 31, 2015 at 6:52 AM, Junade Ali  wrote:
> > I am looking to submit an RFC in order to remove the error suppression
> > operator in PHP, namely the @ symbol.
> >
> Forwarding a suggestion twitter/@Beryllium9:
>
> How about a global "disable error suppression" setting?  That way a
> project lead could enforce it for their codebase (and guarantee that
> devs "aren't lazy"), but PHP doesn't lose its pragmatism?
>
> -Sara
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

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

[Zeev Suraski]

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

RE: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[Zeev Suraski]

> -Original Message-
> From: a...@adamharvey.name [mailto:a...@adamharvey.name] On
> Behalf Of Adam Harvey
> Sent: Tuesday, January 05, 2016 3:46 AM
> To: Stanislav Malyshev
> Cc: PHP internals
> Subject: Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct
>
> On 4 January 2016 at 17:34, Stanislav Malyshev 
> wrote:
> > If we're talking about having a declaration of principles, I am not
> > sure we need elaborate text to say "don't be an ass" but I don't mind
> > having one in case somebody ever need explicit instructions on how
> > exactly not to do that :)
>
> One thing I really like about the covenant Anthony is proposing (besides
> it
> being the same as the one a bunch of other projects are
> using) is that it actually is pretty short, considering what it is.
> The English version fits on one screen on my laptop.

I actually find that a bad thing.  As I think the Voting RFC proved (IMHO
beyond a reasonable doubt) - what's not clearly defined in the text, may
evolve in unpredictable directions in the future.

Specifically, the Contributor Covenant has text which in my opinion, is
either too open for interpretation or needs to be narrowed down - e.g.
'Personal Attacks' and even more so 'Other unethical or unprofessional
conduct'.  What one may find a legitimate part of a heated discussion -
another may find as a personal attack.  What one may consider perfectly
fine - another may find completely unethical.  These are subjective matters
and giving a group of five (or seven, or nine) people judicial power over
them is very problematic.

While I understand the position that even though it's "a solution waiting
for a problem" - proactively providing such a CoC makes sense - I think the
open-endedness and the risk of bad things happening as a result of it are
far greater than any positives.

I would focus on creating as-clear-cut-as-possible CoC (probably a trimmed
down version of the Contributor Covenant), but would leave the 'teeth' part
(i.e. the council part and any sanctions) out.

In the very extreme situations where someone truly needs to be banned or
otherwise sanctioned, any one of us can propose an RFC to do it.  I would
require a 2/3 majority and probably no less than X voters voting in favor of
the ban, given the far-reaching implications (X being at least several dozen
people IMHO).  Personally, I would advise to never issue permanent bans -
people do sometimes change.  People get second chances for doing much worse
things;  I'd go for a 1yr or at most 2yr bans (again, in exceptional cases
only).

My 2c.

Zeev

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

Re: [PHP-DEV] [RFC] [VOTE] PHP 5's Support Timeline

[Derick Rethans]

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

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

Re: [PHP-DEV] Deprecation of the Error Control Operator (@ symbol)

[Rowan Collins]

Grzegorz Zdanowski wrote on 05/01/2016 12:27:

Before deprecating @ operator I think we should make a RFC which cover
unified setting to convert all E_* to exceptions (like
PhpWarningException). I know it's just a temporary solution, because
exception should be more specific, but it's a huge amount of work to
replace all errors and warnings with proper exceptions.


This is definitely not the solution. I've seen this suggested a few 
times over the years, and every time people seem to miss a vital point: 
Warnings are not, in general, a fatal situation. A useful rule of thumb 
I heard for "should I throw an exception?" is "would I be happy to use a 
die() statement?"


Even if you don't accept that, the main purpose of an exception is to 
force the code down a different path. (I've seen lots of discussions 
about exceptions being great because they have stack traces, but have 
never understood why any other mechanism couldn't also have those).


In a few places, like the file-handle API, the Warning is accompanied by 
an invalid return value (usually false) and probably should be an 
exception - the code will definitely need to follow a different path, 
and dying would often be better than proceeding with an invalid handle 
(which will probably end up fatal later).


But in many cases, an E_WARNING (or an E_NOTICE) really is just a 
warning - most code *doesn't* want to go down an alternative path, but 
it might want to log a message. In a few cases, code does want to go 
down a different path, and currently has to use the "error handler" 
infrastructure. In other cases, code wants to never log the message, and 
currently has to use the @ operator.


The main problem, in my opinion, with the current system of "errors" 
(better called "messages") is that they provide only two pieces of 
identifying information: an integer representing severity, from a small 
list; and a string which may have placeholders, may change between 
versions, and does not come from a documented list. This means you can 
say "suppress everything with E_NOTICE severity" but not "suppress all 
array-assignment warnings"; and you can set up an error handler to 
convert everything into exceptions, but a handler to convert all 
file-handle warnings into exceptions would have to pattern-match every 
message string to identify them.


The only way out of this that I can see is to replace the current 
string-based internal message APIs with something that forces the 
extension developer to pre-define a set of codes, and provide the 
substitution parameters for the error directly. This could then allow 
more information to be exposed to userland, and more granular stacking 
of handlers and configuration to mask off different types based on their 
codes.


Regards,
--
Rowan Collins
[IMSoP]

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

[PHP-DEV] Proposed change in json_encode+JSON_UNESCAPED_UNICODE behavior

[Eddie Kohler]

Hi,

I'm proposing a small change in the behavior of `json_encode(str,
JSON_UNESCAPED_UNICODE)` around the issue of line terminators.

The U+2028 LINE SEPARATOR and U+2029 PARAGRAPH SEPARATOR
characters are allowed unescaped in JSON strings, but *not* allowed unescaped
in Javascript. This is widely considered a minor wart in the JSON specification.


As a result, the JSON_UNESCAPED_UNICODE flag is dangerous to use when
generating HTML. For example, this will generate a Javascript error ("Unexpected
token ILLEGAL") in the user's browser:

```
$x = mb_convert_encoding('', 'UTF-8', 'HTML-ENTITIES');
echo 'x = ', json_encode($x, JSON_UNESCAPED_UNICODE), ';';
```

The proposal is for `json_encode(..., JSON_UNESCAPED_UNICODE)` to
escape the U+2028 and U+2029 characters as \u2028 and \u2029. A new flag,
JSON_UNESCAPED_LINE_TERMINATORS, preserves the former behavior.

It's important to note that this change *only* affects the non-default
JSON_UNESCAPED_UNICODE flag.

Jakub Zelenka approves of this change, which we've discussed on Github
, but since it is a small change in
behavior, he asked me to email internals in case anyone objects.

Thanks all,
Eddie Kohler

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

Re: [PHP-DEV] What's up with gcov.php.net?

[Ferenc Kovacs]

On Thu, Dec 31, 2015 at 10:26 AM, Xinchen Hui  wrote:

> Hey:
>
>
> On Thu, Dec 31, 2015 at 5:19 PM, Michael Wallner  wrote:
>
> >
> > > On 30 12 2015, at 22:34, Andrea Faulds  wrote:
> > >
> > > Hi everyone,
> > >
> > > If any of you have looked at http://gcov.php.net any time in the last
> > three years, you'll probably have noticed an alarming and inexplicably
> high
> > number of test failures. And if you've looked at Travis, you'll have seen
> > much more reasonable numbers (i.e. usually zero).
> >
> > A guess might be, that many of the tests run on gcov are disabled on
> > travis.
> >
> > >
> > > So, I'd like to ask, why does gcov.php.net always show such high
> > numbers, and apparently has things that are fixed show up as broken, and
> > secondly, since we use Travis for continuous integration these days, why
> is
> > the box even still running?
> >
> > gcov is about coverage too, so…
> >
> and also valgrind, which is quite useful, since it takes too long to run in
> laptop.
>
> thanks
>
>
which is also explains some of the differences between the test failures,
running the testsuite with valgrind can find much more memory leaks
compared to the simple run-tests run on travis


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

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[Peter Lind]

On 5 January 2016 at 16:59, Stanislav Malyshev  wrote:

> Hi!
>
> > How exactly would you feel about having all of this made explicit to all
> > the other PHP devs? Presumably you look up to some of these people -
>
> I presume you would feel bad. However your example is purely theoretical
> and hand-crafted to exactly fit your argument.


Yes, I thought it up, hence it's theoretical. If you think that means it
hasn't happened countless times along those lines, you need to learn how to
google.



> It is easy to imagine
> theoretical example that found fit practically any argument - including
> one that nobody should have any due process at all, since proving any
> allegations just hurts the victim again (and you can imagine
> unbelievably hurtful circumstances for your theoretical case, since the
> only limit is your imagination), so any allegation should be considered
> true by mere fact of alleging.


Is there any particular reason you feel the need for arguing strawmen? At
which point has *anyone* argued for against due process? If you cannot
point to any such point, would you mind not assuming them?



> I hope that would be going too far for you?
>

See above.


> In practice, there's rarely an allegation that can not be published to
> the measure that makes it clear what happened.


Unless you've been through abuse and harassment along the lines of
http://blog.randi.io/2015/12/31/the-developer-formerly-known-as-freebsdgirl/
I would suggest you stop assuming what it is like.



> That does not mean
> "verbatim" - in some cases, like publishing private information,
> reproducing it verbatim as a proof would be obviously counterproductive,
> but there are also obvious way to describe it without reproducing
> verbatim, such as "publishing private information".
>
>
See above.



> > If you happen to belong to a minority group that often is at the
> > receiving end of abuse, what would you think if this was the message
> > being sent? Would you expect to be understood by your peers, or would
>
> I think the message that is being sent is that everybody will be treated
> equally and fairly. If somebody has done something bad, it would be
> known and the solution would be found, if nothing bad happened, people
> can be reasonably assured that they are safe from false accusations.
> That applies to majorities, minorities, mediocrities and any other
> groups, however one would like to label oneself that particular day.
>

And you would be wrong - that is not the message being sent.

-- 

WWW: plphp.dk / plind.dk
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[Ben Ramsey]

> On Jan 5, 2016, at 10:03 AM, Paul M. Jones  wrote:
> 
> 
>> On Jan 5, 2016, at 09:55, Ben Ramsey  wrote:
>> 
>> 
>>> On Jan 4, 2016, at 10:29 PM, Paul M. Jones  wrote:
>>> 
>>> If there's an accusation, then *due process* needs to be applied. If it 
>>> rises to the level of needing *due process* then the police should be 
>>> involved. There's no need, *none at all*, for a star chamber *or* a mob to 
>>> be an amenable authority to salve someone's hurt feelings and ban someone 
>>> else, not even in a temporary capacity.
>> 
>> Isn’t this RFC setting up the due process?
> 
> (/me shakes head)
> 
> No rights of the accused, for one. Opaque star chamber for another. Vague and 
> indefinable terms for a third. It's a *political* action designed with a 
> *political* intent, to enforce *political* in-group at the expense of a 
> *political* out-group.

I think “no rights of the accused” is a fair criticism. I think Larry brought 
up a valid criticism when he said:

> I am a firm believer in the right to face one's accusers.

Let’s assume for a moment we need a code of conduct and/or diversity statement; 
we want to set up rules to govern ourselves in the event that a situation 
arises when someone is legitimately facing harassment in our community. Let’s 
assume the harassment is not life-threatening, nor is it threatening bodily 
harm, so law enforcement isn’t a viable course of action.

What should those governance rules look like for our community?

Anthony has already proposed one form of rules. There is some good criticism of 
these rules: they are too vague, they do not provide protections for the 
accused, too much power is given to a small body, the “public spaces” clause is 
too far-reaching, the rules can be used to silence speech that is unfavorable 
even if it isn’t harassment.

There are groups of excellent programmers who would benefit our community with 
their ideas and contributions, but they feel marginalized and are not 
comfortable taking part in our community without an indication that they are 
welcome to participate and that we are a safe community for them. Should we 
have any form of statement or guidelines to show we are welcoming to all 
people? If we are welcoming to all people, how do we resolve conflicts within 
our community, and how do we enforce resolutions?

Nate pointed to Paul’s “Be Nice” statement for the Solar Framework. I think 
that’s a good start for such a welcoming statement, but what happens when 
someone is not being nice? What is an appropriate course of action?

-Ben



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[Mark Baker]

On 05/01/2016 15:59, François Laupretre wrote:


Anyway, I don't say that it cannot happen, I just say that, AFAIK, we 
never got such concerns in the PHP community. So, maybe we should go 
the 'politically-correct' way but I'm afraid that's just a waste of 
time or, as Stas said, a solution for no problem.


How do you know that you haven't got problems already? It may well be 
that people are put off from joining internals precisely because they 
have nothing to tell them the environment won't be hostile toward them, 
and there's been enough adverse publicity in the past about how "toxic" 
internals is, and enough adverse publicity about other Open Source 
groups that are abusive but you'd never know how many people wanted 
to contribute but were put off... Having a public CoC is a way of 
telling potential supporters/contributors who are thinking about getting 
involved that they can do so without needing to worry about abuse.


--
Mark Baker

 _
|.  \ \-3
|_J_/ PHP |
|| |  __  |
|| |m|  |m|

 I LOVE PHP


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

[PHP-DEV] Re: [RFC] [Draft] Adopt Code of Conduct

[Anthony Ferrara]

All,

On Mon, Jan 4, 2016 at 4:06 PM, Anthony Ferrara  wrote:
> Hey all,
>
> I have created a new RFC for the PHP Project to adopt the Contributor
> Covenant as the official Code of Conduct for the project
>
> https://wiki.php.net/rfc/adopt-code-of-conduct
>
> Let me know what you think or if there are any concerns
>
> Thanks
>
> Anthony

In response to significant feedback here and elsewhere, I have
expanded the text of the RFC significantly. It now includes the text
of the Contributor Covenant 1.3.0 as well as including verbage about
updating it requiring an RFC.

I included a vote requirement for course of actions of 4/5 of the CoC team.

I also included content about the "Reasonable Person Test", explicitly
stating that it shall be assumed that both parties are acting as
reasonable people until proven otherwise by significant evidence. It
also stipulates that reporting an incident does not excuse someone
from the CoC (meaning victims are still bound to follow it, and are
not excused from proper behavior because of a violation).

I also made it explicit that potential actions should be a last
resort, and that the CoC team should make every reasonable attempt to
defuse the situation without having to resort to "punishment".

I also removed the ability to remove commit karma from the team,
instead including that in the "ban" category (meaning that the CoC
team is no longer allowed to remove commit karma long-term without the
action of internals@)

Additionally, I added a line specifying that bans (temporary or
permanent) should only be used in egregious cases.

I added a section on transparency, Conflict of Interest (though this
needs expanding) and accountability (giving internals@ the ability to
"overturn" any action by the CoC team with a vote of 50%+1). I also
made it explicit that accused people have a right to confidentiality
as long as no action is taken by the team.

I also added a section on appeals.

Those are the changes to the RFC as it stands. Please review them.



As to the comments in this thread, I won't reply to every one, but
here are a few points I'd like to make.

It's been mentioned that we may want to adopt a CoC, but it shouldn't
"have teeth". I disagree here, as without an enforcement mechanism it
basically is no different from where we are at today. Saying we should
act reasonable is fine, but we need a method for what we are to do
when one of us acts unreasonably. Additionally, as has been stated,
requiring people to report publicly creates a barrier to entry. Many
people will simply chose to leave quietly rather than report publicly.
Simply look at the way people who speak out about harassment are
treated in public to understand why. The point of the CoC is to create
a safe place for everyone to contribute, not just those with thick
skin.

As to why the Contributor Covenant as opposed to another CoC or our
own custom one, there are two reasons for this. First, it's a standard
that's been adopted by a number of significant scale projects. Second,
it saves us from having to bikeshed over every single word of a CoC.
If there's another standard CoC that we should entertain, I'm happy to
look at it. But I do not believe that we should create our own.

As far as the conflict resolution process, that I am open to expanding
or retracting as much as practical. I do think it's important to have,
but would be happy to take advice from groups like Drupal who have
done this before.

To those that say this is a solution in search of a problem, it very
well may be. But that doesn't mean it isn't important to do. You could
say the same thing about smoke detectors. Even if you've never had a
fire, that doesn't mean it isn't good practice to install protection
from one. In this case, we simply do not know if or how many
contributors we may have lost due to incidents covered by a CoC. Even
if that number is 0, does that mean it's not worth installing one to
prevent it in the future?

Thanks,

Anthony

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

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[Pierre Joye]

On Jan 5, 2016 11:13 PM, "Derick Rethans"  wrote:
>
> On Tue, 5 Jan 2016, François Laupretre wrote:
>
> > Le 05/01/2016 15:31, Peter Lind a écrit :
> >
> > > A quick question: suppose you're from a minority group, and you've
been the
> > > target of abuse previously your life. You now join the PHP community
and for
> > > whatever reason, someone takes a dislike to you and starts harassing
you in
> > > private. The abuse makes use of the same stuff you've been through
before,
> > > and because this is a real douchebag, some very humiliating things are
> > > thrown in for good measure. How exactly would you feel about having
all of
> > > this made explicit to all the other PHP devs? Presumably you look up
to some
> > > of these people - would your first thought be "Oh I know! I'll post
all this
> > > nasty stuff to a public mailing list, that is archived on the web
where
> > > EVERYONE can see all the humiliation coming my way - and where google
is
> > > sure to pick up all these things about me!"? If you happen to belong
to a
> > > minority group that often is at the receiving end of abuse, what
would you
> > > think if this was the message being sent? Would you expect to be
understood
> > > by your peers, or would their concern about being possibly accused of
> > > something seem like an out-of-hand rejection? Regards Peter
> >
> > You're probably right but that all sounds too 'american' to me. These
> > questions of 'minority group' refer to a multi-cultural situation that
is
> > totally foreign to my culture. But I understand it may be an important
concern
> > for others.
>
> It doesn't even have to be a minority group:
> https://www.youtube.com/watch?v=V4UWxlVvT1A
>
> > Anyway, I don't say that it cannot happen, I just say that, AFAIK, we
> > never got such concerns in the PHP community.
>
> Sorry - not true. I can name several issues from various PHP related
> conferences. Although not directly under the "control" of the PHP
> developers team (and hence not influenced by a proposed CoC), they're
> certainly part of the community.

Same here. And in the core as well. Even relatively recently.

I would love to see more focus on how to make this out in a fork we can all
agree on instead of arguing about the rights of one or the other, all
parties will have the same rights. Or to argue about whether such bad event
can happen or not. It will too late to do it when it will happen again.
This alone is a good enough reason to do it, now.

About anonymity, it is also critical during the whole investigation and
afterwards. The reasons are rather obvious for both parties and have been
explained here.

A quick but well thought reaction is vital. In case of an harassment, the
group can take measure and "officially" request to stop any private contact
with the victim. Whether the accused person is guilty or not is not
relevant at this stage. It will help to protect both parties.

I am also convinced that we need one  now more than ever before. Not
because we have more issues (or less) but because we are in a position now
to actually setup such CoC in a good way. And we are also the leading web
programming language. We must ensure that we act accordingly. I also trust
us to have the structure to manage such situations in a fair manner.

Cheers,
Pierre

[PHP-DEV] Help Design a New Cryptography API for PHP 7.1

[Scott Arciszewski]

TL;DR, make this part of PHP 7.1:

   $cipher = new Php\Crypto\Symmetric([
'driver' => 'openssl'
]);
$key = $cipher->deriveKey(
$someUserProvidedPasswordString,
   $someHardCodedSalt
);
$encrypted = $cipher->encrypt($message, $key);

I'm developing a userland prototype in PHP here, so hopefully anyone
can join in even if you're not fluent in C:
https://github.com/paragonie/pco_prototype

Once we're happy with how the API functions, and what the
default/allowed parameters will be for each driver, we can start
writing the PHP extension and move forward with the RFC to merge it.

Here's an overview of the project:

* The API (what we're discussing)
* The drivers (we don't develop these)
* Libsodium
* OpenSSL
* Room to grow in case we need to adopt for a post-quantum
cryptography library

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises 

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

Re: [PHP-DEV] Deprecation of the Error Control Operator (@ symbol)

[Sara Golemon]

On Tue, Jan 5, 2016 at 3:57 AM, Zeev Suraski  wrote:
>> From: Derick Rethans [mailto:der...@php.net]
>> That's going to mean an INI setting.. that hosters could abuse.
>> Having an INI setting like this as part of core is IMO not a great idea.
>
I honestly don't understand why that's a bad idea.  There are a LOT of
settings that hosters could abuse, but as a general rule they don't,
because it breaks client apps and clients leave.

A hoster could just as easily install XDebug and turn that setting on.
Are they doing that?

Or are you, Derick Rethans, suggesting that installing XDebug is a bad idea? ;)

> I agree.  Perhaps through a declare() statement instead?  We could easily
> make it file-based, so that the declare() statement only affects the local
> file, or we could make it global for the entire request.
>
Eh, feels very tomato-tomato to me.  Trading in a line in
php.ini/.htaccess/index.php for a line in index.php.  Ultimately I'm
the wrong person to defend this since I don't personally have a need
for it, I was just trying to offer compromises.

For context, I do believe the person suggesting it was thinking in
terms of "Finding that fatal error that's been supressed."

-Sara

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

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[Derick Rethans]

On Tue, 5 Jan 2016, François Laupretre wrote:

> Le 05/01/2016 15:31, Peter Lind a écrit :
>
> > A quick question: suppose you're from a minority group, and you've been the
> > target of abuse previously your life. You now join the PHP community and for
> > whatever reason, someone takes a dislike to you and starts harassing you in
> > private. The abuse makes use of the same stuff you've been through before,
> > and because this is a real douchebag, some very humiliating things are
> > thrown in for good measure. How exactly would you feel about having all of
> > this made explicit to all the other PHP devs? Presumably you look up to some
> > of these people - would your first thought be "Oh I know! I'll post all this
> > nasty stuff to a public mailing list, that is archived on the web where
> > EVERYONE can see all the humiliation coming my way - and where google is
> > sure to pick up all these things about me!"? If you happen to belong to a
> > minority group that often is at the receiving end of abuse, what would you
> > think if this was the message being sent? Would you expect to be understood
> > by your peers, or would their concern about being possibly accused of
> > something seem like an out-of-hand rejection? Regards Peter 
> 
> You're probably right but that all sounds too 'american' to me. These
> questions of 'minority group' refer to a multi-cultural situation that is
> totally foreign to my culture. But I understand it may be an important concern
> for others.

It doesn't even have to be a minority group:
https://www.youtube.com/watch?v=V4UWxlVvT1A

> Anyway, I don't say that it cannot happen, I just say that, AFAIK, we 
> never got such concerns in the PHP community.

Sorry - not true. I can name several issues from various PHP related 
conferences. Although not directly under the "control" of the PHP 
developers team (and hence not influenced by a proposed CoC), they're 
certainly part of the community.

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

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[François Laupretre]

Le 05/01/2016 15:31, Peter Lind a écrit :
A quick question: suppose you're from a minority group, and you've 
been the target of abuse previously your life. You now join the PHP 
community and for whatever reason, someone takes a dislike to you and 
starts harassing you in private. The abuse makes use of the same stuff 
you've been through before, and because this is a real douchebag, some 
very humiliating things are thrown in for good measure. How exactly 
would you feel about having all of this made explicit to all the other 
PHP devs? Presumably you look up to some of these people - would your 
first thought be "Oh I know! I'll post all this nasty stuff to a 
public mailing list, that is archived on the web where EVERYONE can 
see all the humiliation coming my way - and where google is sure to 
pick up all these things about me!"? If you happen to belong to a 
minority group that often is at the receiving end of abuse, what would 
you think if this was the message being sent? Would you expect to be 
understood by your peers, or would their concern about being possibly 
accused of something seem like an out-of-hand rejection? Regards Peter 


You're probably right but that all sounds too 'american' to me. These 
questions of 'minority group' refer to a multi-cultural situation that 
is totally foreign to my culture. But I understand it may be an 
important concern for others.


Anyway, I don't say that it cannot happen, I just say that, AFAIK, we 
never got such concerns in the PHP community. So, maybe we should go the 
'politically-correct' way but I'm afraid that's just a waste of time or, 
as Stas said, a solution for no problem.


Regards

François

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

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[Larry Garfield]

On 1/5/16 11:08 AM, Pierre Joye wrote:

Anyway, I don't say that it cannot happen, I just say that, AFAIK, we
never got such concerns in the PHP community.

Sorry - not true. I can name several issues from various PHP related
conferences. Although not directly under the "control" of the PHP
developers team (and hence not influenced by a proposed CoC), they're
certainly part of the community.

Same here. And in the core as well. Even relatively recently.

I would love to see more focus on how to make this out in a fork we can all
agree on instead of arguing about the rights of one or the other, all
parties will have the same rights. Or to argue about whether such bad event
can happen or not. It will too late to do it when it will happen again.
This alone is a good enough reason to do it, now.

About anonymity, it is also critical during the whole investigation and
afterwards. The reasons are rather obvious for both parties and have been
explained here.

A quick but well thought reaction is vital. In case of an harassment, the
group can take measure and "officially" request to stop any private contact
with the victim. Whether the accused person is guilty or not is not
relevant at this stage. It will help to protect both parties.

I am also convinced that we need one  now more than ever before. Not
because we have more issues (or less) but because we are in a position now
to actually setup such CoC in a good way. And we are also the leading web
programming language. We must ensure that we act accordingly. I also trust
us to have the structure to manage such situations in a fair manner.

Cheers,
Pierre


Who would like to be connected with the Drupal people in this space, if 
I can get their time?  I figure Anthony and Stas are good to include 
there (proposer and someone with well-reasoned concerned). One or two 
more people?


--
--Larry Garfield


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

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[Scott Arciszewski]

On Tue, Jan 5, 2016 at 11:08 AM, Mark Baker  wrote:
> On 05/01/2016 15:59, François Laupretre wrote:
>>
>>
>> Anyway, I don't say that it cannot happen, I just say that, AFAIK, we
>> never got such concerns in the PHP community. So, maybe we should go the
>> 'politically-correct' way but I'm afraid that's just a waste of time or, as
>> Stas said, a solution for no problem.
>>
> How do you know that you haven't got problems already? It may well be that
> people are put off from joining internals precisely because they have
> nothing to tell them the environment won't be hostile toward them, and
> there's been enough adverse publicity in the past about how "toxic"
> internals is, and enough adverse publicity about other Open Source groups
> that are abusive but you'd never know how many people wanted to
> contribute but were put off... Having a public CoC is a way of telling
> potential supporters/contributors who are thinking about getting involved
> that they can do so without needing to worry about abuse.
>
> --
> Mark Baker
>
>  _
> |.  \ \-3
> |_J_/ PHP |
> || |  __  |
> || |m|  |m|
>
>  I LOVE PHP
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Hi all,

Even if there are no incidencts where a CoC is needed, after seeing
today's Reddit thread, I'm convinced it's only a matter of time.

https://www.reddit.com/r/PHP/comments/3zhapd/rfc_adopt_code_of_conduct

Just my $0.02

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises

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

Re: [PHP-DEV] Re: RFC Operator Overloading in Userspace

[Stanislav Malyshev]

Hi!

> Interface is a good way to implement new functionality for classes, but
> operator overloading is language feature itself, so from my point of view,
> it will be better to put this functionality into the magic method.

No contradiction here. Language features can use interfaces, see
Throwable or ArrayAccess.

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

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

Re: [PHP-DEV] Deprecation of the Error Control Operator (@ symbol)

[Andrea Faulds]

Hi Sara,

Sara Golemon wrote:

On Thu, Dec 31, 2015 at 6:52 AM, Junade Ali  wrote:

I am looking to submit an RFC in order to remove the error suppression
operator in PHP, namely the @ symbol.


Forwarding a suggestion twitter/@Beryllium9:

How about a global "disable error suppression" setting?  That way a
project lead could enforce it for their codebase (and guarantee that
devs "aren't lazy"), but PHP doesn't lose its pragmatism?


I don't think that would work out too well. Remember that many projects 
have error handles which convert all errors to exceptions: if you 
disable @ in those projects, wouldn't their code break?


Thanks.
--
Andrea Faulds
https://ajf.me/

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

Re: [PHP-DEV] Push Litespeed SAPI 6.9 to PHP 7.0.1

[Tom Sommer]

On 2015-12-24 12:18, Lior Kaplan wrote:

On Thu, Dec 24, 2015 at 1:09 PM, Tom Sommer  wrote:


On 2015-12-16 14:41, Tom Sommer wrote:


Hi

I realise 7.0.1 is already out in RC1, but there is a bug in the
Litespeed 6.8 sapi which breaks php_flag and php_value. It's causing
our customers a lot of headaches.

I see Litespeed 6.9 is already in master, but would it be possible to
get backported into 7.0.1?

The fix is here:

https://github.com/php/php-src/commit/5bcb7a7019a49c2f80eda7d2aa947efebeee0034#diff-e8087496f5a642ce83e5d655c08c6b3a
(I believe)



So noone is going to do anything about this? It's not in 7.0.2 either?



Please contact the original committer to understand why was it done in
master only.

George Wang 

He is the de-facto maintainer for the lightspeed sapi.


Pull request into 7.0 branch: https://github.com/php/php-src/pull/1715

I can create one for 7.0.2 also ;)

// Tom

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

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[Ben Ramsey]

> On Jan 4, 2016, at 10:29 PM, Paul M. Jones  wrote:
> 
> If there's an accusation, then *due process* needs to be applied. If it rises 
> to the level of needing *due process* then the police should be involved. 
> There's no need, *none at all*, for a star chamber *or* a mob to be an 
> amenable authority to salve someone's hurt feelings and ban someone else, not 
> even in a temporary capacity.

Isn’t this RFC setting up the due process?

If you harass someone at work, there are review processes and you get fired. In 
fact, in most states, you don’t need a reason to get fired. You just get fired. 
They don’t call the police unless they need to press charges for a criminal 
offense.

Why shouldn’t a public open source project set up rules and processes for 
“firing” someone from the project if they harass someone?

-Ben


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [PHP-DEV] RFC Operator Overloading in Userspace

[Bob Weinand]

> Am 05.01.2016 um 15:29 schrieb Alexander Lisachenko :
> 
> 2016-01-05 2:04 GMT+03:00 Andrea Faulds :
> 
>> I agree that we could do something with interfaces. I would like to point
>> out that we actually already have an example of this, in the form of the
>> \ArrayAccess interface, which requires you to implement all the different
>> indexing operations at once. Unfortunately, though, \ArrayAccess doesn't
>> give us a precedent for dealing with the $this issue (in `$a + $b`, who
>> gets called, how do we handle differing types, etc?), but it's a start.
>> 
> 
> 
> Hi, Andrea and internals team!
> 
> Interface is a good way to implement new functionality for classes, but
> operator overloading is language feature itself, so from my point of view,
> it will be better to put this functionality into the magic method.
> Personally, I don't like hundreds of __add, __mul, __etc methods, because
> this will be ugly and will require addition of new methods when new
> operators are included (eg __pow).
> 
> I want to suggest to add only one single method:
> 
> public function __operator(int $operatorKind, ...$operatorArgs);
> 
> This method will be called for every operator and class can check the
> $operatorKind variable with simple check: if (Php\Operator::OP_DIVISION ===
> $operatorKind) return $operatorArgs[0]->value / $operatorArgs[1]->value;
> New values for operator type enumeration can be added later into new
> versions of PHP easily.

I think an interface is a strongly superior way, especially as it'll allow you 
to hint that an implementation became incomplete when an operator has been 
added. (Also, how often are relevant operators added?)
At least as you aren't supposed to *ab*use the methods for other things than 
they're intended to. If you implement number operations, then you should 
implement the whole set of them.
If you implement a string class, you should implement the array access and the 
string concat.

Operators definitely shouldn't have specific context sensitive meaning (like 
printing when you bitshift (wtf, C++?)).
At least, we should *assume* that the operators are used in accord with their 
intended meaning.

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

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[Stanislav Malyshev]

Hi!

> How exactly would you feel about having all of this made explicit to all
> the other PHP devs? Presumably you look up to some of these people -

I presume you would feel bad. However your example is purely theoretical
and hand-crafted to exactly fit your argument. It is easy to imagine
theoretical example that found fit practically any argument - including
one that nobody should have any due process at all, since proving any
allegations just hurts the victim again (and you can imagine
unbelievably hurtful circumstances for your theoretical case, since the
only limit is your imagination), so any allegation should be considered
true by mere fact of alleging. I hope that would be going too far for you?
In practice, there's rarely an allegation that can not be published to
the measure that makes it clear what happened. That does not mean
"verbatim" - in some cases, like publishing private information,
reproducing it verbatim as a proof would be obviously counterproductive,
but there are also obvious way to describe it without reproducing
verbatim, such as "publishing private information".

> If you happen to belong to a minority group that often is at the
> receiving end of abuse, what would you think if this was the message
> being sent? Would you expect to be understood by your peers, or would

I think the message that is being sent is that everybody will be treated
equally and fairly. If somebody has done something bad, it would be
known and the solution would be found, if nothing bad happened, people
can be reasonably assured that they are safe from false accusations.
That applies to majorities, minorities, mediocrities and any other
groups, however one would like to label oneself that particular day.
-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[Paul M. Jones]

> On Jan 5, 2016, at 09:55, Ben Ramsey  wrote:
> 
> 
>> On Jan 4, 2016, at 10:29 PM, Paul M. Jones  wrote:
>> 
>> If there's an accusation, then *due process* needs to be applied. If it 
>> rises to the level of needing *due process* then the police should be 
>> involved. There's no need, *none at all*, for a star chamber *or* a mob to 
>> be an amenable authority to salve someone's hurt feelings and ban someone 
>> else, not even in a temporary capacity.
> 
> Isn’t this RFC setting up the due process?

(/me shakes head)

No rights of the accused, for one. Opaque star chamber for another. Vague and 
indefinable terms for a third. It's a *political* action designed with a 
*political* intent, to enforce *political* in-group at the expense of a 
*political* out-group.


-- 
Paul M. Jones
pmjone...@gmail.com
http://paul-m-jones.com

Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp

Solving the N+1 Problem in PHP
https://leanpub.com/sn1php



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

Re: [PHP-DEV] Re: RFC Operator Overloading in Userspace

[Alexander Lisachenko]

2016-01-05 2:04 GMT+03:00 Andrea Faulds :

> I agree that we could do something with interfaces. I would like to point
> out that we actually already have an example of this, in the form of the
> \ArrayAccess interface, which requires you to implement all the different
> indexing operations at once. Unfortunately, though, \ArrayAccess doesn't
> give us a precedent for dealing with the $this issue (in `$a + $b`, who
> gets called, how do we handle differing types, etc?), but it's a start.
>


Hi, Andrea and internals team!

Interface is a good way to implement new functionality for classes, but
operator overloading is language feature itself, so from my point of view,
it will be better to put this functionality into the magic method.
Personally, I don't like hundreds of __add, __mul, __etc methods, because
this will be ugly and will require addition of new methods when new
operators are included (eg __pow).

I want to suggest to add only one single method:

public function __operator(int $operatorKind, ...$operatorArgs);

This method will be called for every operator and class can check the
$operatorKind variable with simple check: if (Php\Operator::OP_DIVISION ===
$operatorKind) return $operatorArgs[0]->value / $operatorArgs[1]->value;
New values for operator type enumeration can be added later into new
versions of PHP easily.

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[Peter Lind]

>
> +1. The proposed CoC is too vague for a multi-cultural environment like
> ours. Reference to ethics, for example, is subjective by nature. But I'm OK
> for a more precise text that everybody must explicitely approve before
> getting any karma.
>
> But I am opposed to any form of law enforcement board. I understand it
> ensures privacy but my feeling is that we don't need privacy here, and we
> never needed such a mechanism during 20 years. Most questionable messages
> are published on the mailing list. If someone receives an offending private
> mail or is victim of harassment in any other way, he can just publish it on
> the list and everyone will judge if it is offending or not. Then, if we
> need to consider banning someone, anybody can create a specific RFC for
> this, but it is an extreme case that, fortunately, has a very low
> probability..
>

A quick question: suppose you're from a minority group, and you've been the
target of abuse previously your life. You now join the PHP community and
for whatever reason, someone takes a dislike to you and starts harassing
you in private. The abuse makes use of the same stuff you've been through
before, and because this is a real douchebag, some very humiliating things
are thrown in for good measure.

How exactly would you feel about having all of this made explicit to all
the other PHP devs? Presumably you look up to some of these people - would
your first thought be "Oh I know! I'll post all this nasty stuff to a
public mailing list, that is archived on the web where EVERYONE can see all
the humiliation coming my way - and where google is sure to pick up all
these things about me!"?

If you happen to belong to a minority group that often is at the receiving
end of abuse, what would you think if this was the message being sent?
Would you expect to be understood by your peers, or would their concern
about being possibly accused of something seem like an out-of-hand
rejection?

Regards
Peter

-- 

WWW: plphp.dk / plind.dk
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[Ryan Pallas]

On Jan 5, 2016 7:32 AM, "Peter Lind"  wrote:
>
> >
> > +1. The proposed CoC is too vague for a multi-cultural environment like
> > ours. Reference to ethics, for example, is subjective by nature. But
I'm OK
> > for a more precise text that everybody must explicitely approve before
> > getting any karma.
> >
> > But I am opposed to any form of law enforcement board. I understand it
> > ensures privacy but my feeling is that we don't need privacy here, and
we
> > never needed such a mechanism during 20 years. Most questionable
messages
> > are published on the mailing list. If someone receives an offending
private
> > mail or is victim of harassment in any other way, he can just publish
it on
> > the list and everyone will judge if it is offending or not. Then, if we
> > need to consider banning someone, anybody can create a specific RFC for
> > this, but it is an extreme case that, fortunately, has a very low
> > probability..
> >
>
> A quick question: suppose you're from a minority group, and you've been
the
> target of abuse previously your life. You now join the PHP community and
> for whatever reason, someone takes a dislike to you and starts harassing
> you in private. The abuse makes use of the same stuff you've been through
> before, and because this is a real douchebag, some very humiliating things
> are thrown in for good measure.
>
> How exactly would you feel about having all of this made explicit to all
> the other PHP devs? Presumably you look up to some of these people - would
> your first thought be "Oh I know! I'll post all this nasty stuff to a
> public mailing list, that is archived on the web where EVERYONE can see
all
> the humiliation coming my way - and where google is sure to pick up all
> these things about me!"?
>
> If you happen to belong to a minority group that often is at the receiving
> end of abuse, what would you think if this was the message being sent?
> Would you expect to be understood by your peers, or would their concern
> about being possibly accused of something seem like an out-of-hand
> rejection?
>
> Regards
> Peter
>
I completely agree with Peter on this one. If my only source for recompense
is to post publicly, I'm far more likely to leave the community than post
anything I find harassing publicly.
> --
> 
> WWW: plphp.dk / plind.dk
> CV: careers.stackoverflow.com/peterlind
> LinkedIn: plind
> Twitter: kafe15
> 

[PHP-DEV] BAD Benchmark Results for PHP Master 2016-01-05

[lp_benchmark_robot]

Results for project PHP master, build date 2016-01-05 06:30:04+02:00
commit: 928d2cb
previous commit:65e456f
revision date:  2016-01-04 18:14:08+01:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, 
stepping 2, LLC 45 MB
mem:128 GB
os: CentOS 7.1
kernel: Linux 3.10.0-229.4.2.el7.x86_64

Baseline results were generated using release php-7.0.0, with hash 60fffd2 from
2015-12-01 04:16:47+00:00

---
benchmark   relative   change since   change since  
current rev run
std_dev*   last run   baseline  
   with PGO
---
:-|   Wordpress 4.2.2 cgi -T1  0.17%  0.22%  0.40%  
  7.27%
:-|   Drupal 7.36 cgi -T1  0.14% -0.18% -0.09%  
  4.35%
:-|   MediaWiki 1.23.9 cgi -T5000  0.13% -1.16%  0.32%  
  3.14%
:-(   bench.php cgi -T100  0.01% -1.63% -0.20%  
  6.35%
:-)  micro_bench.php cgi -T10  0.05%  0.96%  0.93%  
  3.40%
:-(  mandelbrot.php cgi -T100  0.01% -2.35%-14.77%  
  1.23%
---
* Relative Standard Deviation (Standard Deviation/Average)
Note: Benchmark results for Wordpress, Drupal, MediaWiki are measured in
fetches/second while all others are measured in seconds.
More details on measurements methodology at: 
https://01.org/lp/documentation/php-environment-setup.

Subject Label Legend:
Attributes are determined based on the performance evolution of the workloads
compared to the previous measurement iteration.
NEUTRAL: performance did not change by more than 1% for any workload
GOOD: performance improved by more than 1% for at least one workload and there
is no regression greater than 1%
BAD: performance dropped by more than 1% for at least one workload and there is
no improvement greater than 1%
UGLY: performance improved by more than 1% for at least one workload and also
dropped by more than 1% for at least one workload


Our lab does a nightly source pull and build of the PHP project and measures
performance changes against the previous stable version and the previous nightly
measurement. This is provided as a service to the community so that quality
issues with current hardware can be identified quickly.

Intel technologies' features and benefits depend on system configuration and may
require enabled hardware, software or service activation. Performance varies
depending on system configuration.


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

Re: [PHP-DEV] [RFC] Normalize token_get_all() output (with flag)

[Nikita Popov]

On Mon, Jan 4, 2016 at 11:56 PM, Sara Golemon  wrote:

> I swear, 2016 isn't going to be "An RFC per day" year, but...
>
> https://wiki.php.net/rfc/token-get-always-tokens
>
> This should be pretty non-controversial.  I hope?
>
>
+1

Would be nice if someone could come up with a more explicit name for the
flag. TOKEN_FULL is not obvious, at least to me. TOKEN_ALWAYS_ARRAY?

I'd also like to have a flag TOKEN_NO_LINENOS with deduplication of token
arrays, but that's a separate matter...

Nikita

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[Rowan Collins]

Paul M. Jones wrote on 05/01/2016 16:03:

It's a*political*  action designed with a*political*  intent


Please stop assuming that everybody has a hidden agenda at odds with 
their public statements, and claiming that you somehow know that the 
negative possibilities of this policy are deliberately in service of its 
secret aim, rather than unintended consequences of its stated aim.


If you dislike the details of this proposal, that is fine, and you can 
explain what you don't like about it, and what you would prefer instead 
- e.g. a "be nice" policy without explicit teeth, or total anarchy and 
the right to insult, threaten, and bully whoever you choose because you 
honestly believe that "free speech" trumps all other moral and pragmatic 
considerations.


Bear in mind you will be expected to defend that position, and that 
people have the right to disagree with you, and attempt to find common 
ground and compromises. That's how conversations work.


If all you're doing is trolling the group because you think being rude 
on a thread about good conduct is funny, please go do it on 4chan or 
reddit or something.


Regards,
--
Rowan Collins
[IMSoP]

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[Stanislav Malyshev]

Hi!

> That is the problem: you cannot discuss how to protect the accused
> without having the context of the abused. As you have yourself pointed
> out with examples, it is a tradeoff.

But that is exactly what I want - to have full(er) context! The secret
procedure makes that harder. Of course, there are tradeoffs and some
details must be withheld - but the first version of RFC (did not read
the new one yet) was "maximum confidentiality", and that's not good IMO.
I think the default should be "maximum disclosure, unless it's obviously
damaging (personal data, etc.) or no-content (insults, slurs, etc.)".
I.e. I recognize there's no absolute, I just want the balance be different.

> That is a truism: doing more damage is not fixing anything. However,
> unless I am mistaken, you yourself put forward the lack of explicit
> problems as an argument in favour of not doing anything.

Right. So that's one point of discussion - should we do anything at all
or not. But if we *are* doing something - that's the second point of
discussion - namely, institute new structure with broad powers in the
community - we should do it in a way that is least likely to cause damage.

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

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

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[Ferenc Kovacs]

On Tue, Jan 5, 2016 at 6:37 PM, Larry Garfield 
wrote:

> On 1/5/16 11:08 AM, Pierre Joye wrote:
>
>> Anyway, I don't say that it cannot happen, I just say that, AFAIK, we
 never got such concerns in the PHP community.

>>> Sorry - not true. I can name several issues from various PHP related
>>> conferences. Although not directly under the "control" of the PHP
>>> developers team (and hence not influenced by a proposed CoC), they're
>>> certainly part of the community.
>>>
>> Same here. And in the core as well. Even relatively recently.
>>
>> I would love to see more focus on how to make this out in a fork we can
>> all
>> agree on instead of arguing about the rights of one or the other, all
>> parties will have the same rights. Or to argue about whether such bad
>> event
>> can happen or not. It will too late to do it when it will happen again.
>> This alone is a good enough reason to do it, now.
>>
>> About anonymity, it is also critical during the whole investigation and
>> afterwards. The reasons are rather obvious for both parties and have been
>> explained here.
>>
>> A quick but well thought reaction is vital. In case of an harassment, the
>> group can take measure and "officially" request to stop any private
>> contact
>> with the victim. Whether the accused person is guilty or not is not
>> relevant at this stage. It will help to protect both parties.
>>
>> I am also convinced that we need one  now more than ever before. Not
>> because we have more issues (or less) but because we are in a position now
>> to actually setup such CoC in a good way. And we are also the leading web
>> programming language. We must ensure that we act accordingly. I also trust
>> us to have the structure to manage such situations in a fair manner.
>>
>> Cheers,
>> Pierre
>>
>
> Who would like to be connected with the Drupal people in this space, if I
> can get their time?  I figure Anthony and Stas are good to include there
> (proposer and someone with well-reasoned concerned). One or two more people?
>
> --
> --Larry Garfield
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Maybe Sarah and Paul and with that we covered every angle :)

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

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[Paul M. Jones]

> On Jan 5, 2016, at 13:20, Anthony Ferrara  wrote:
> 
> Paul isn't trolling. He is simply passionate about it. While I do
> believe he can be more constructive with how he interacts in this
> specific thread, he definitely isn't trolling (trying to cause drama
> for drama's sake). We should be careful about that term and use it
> appropriately.

This is one of the reasons I like you, Anthony, and I appreciate your 
understanding.


-- 
Paul M. Jones
pmjone...@gmail.com
http://paul-m-jones.com

Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp

Solving the N+1 Problem in PHP
https://leanpub.com/sn1php



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

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[Peter Lind]

On 5 January 2016 at 19:53, Stanislav Malyshev  wrote:

> Hi!
>
> > Yes, I thought it up, hence it's theoretical. If you think that means it
> > hasn't happened countless times along those lines, you need to learn how
> > to google.
>
> I hope you realize how weak is an argument along the lines of "I am
> right, if you don't see it, learn how to google".
>
>
I'm sorry. I, wrongly, assumed that it was common knowledge by now how
toxic the tech environment and culture can be, and how many people have
been abused and harassed, both online and offline.



> > Is there any particular reason you feel the need for arguing strawmen?
> > At which point has *anyone* argued for against due process? If you
> > cannot point to any such point, would you mind not assuming them?
> >
> >
> >
> > I hope that would be going too far for you?
> >
> >
> > See above.
>
> As you see, I have assumed exactly the opposite: that you are *not*
> against due process. That's what "going too far" means. You are merely
> using an argument that proves too much
> (https://en.wikipedia.org/wiki/Proving_too_much) - following that
> argument, we could conclude that due process is bad. Which is an absurd
> conclusion - that's how reductio ad absurdum works.
>
>
You argued against a strawman. I pointed that out. One of us was misreading
something, and seeing as you put the argument with no due process
whatsoever forward, I thought it was you. My mistake.



> > Unless you've been through abuse and harassment along the lines
> > of
> http://blog.randi.io/2015/12/31/the-developer-formerly-known-as-freebsdgirl/
> > I would suggest you stop assuming what it is like.
>
> I can not stop it since I never started. But what is like, however bad
> it is, is not an argument for what we are discussing, since we do not
> argue what happened there is good. We argue whether adopting the RFC is
> a good way to prevent something like that from happening or reduce its
> incidence. Saying "introducing safe mode is not a good way to improve
> security" is not the same as saying "we need no security" :)
>
>
It seems to me you did in fact assume that things could be handled
transparently on the mailing list - as that was the proposed solution you
put forward. I then pointed to a specific case that I doubt most people
would be happy about making public.

And yes, we're discussing how to best handle things. My specific point was
that requiring people to post to the mailing list if they have any
grievances is not a good idea. Doesnt mean that the watchmen shouldn't be
watched.

-- 

WWW: plphp.dk / plind.dk
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[Peter Lind]

On 5 January 2016 at 20:26, Stanislav Malyshev  wrote:

> Hi!
>
> > That is the problem: you cannot discuss how to protect the accused
> > without having the context of the abused. As you have yourself pointed
> > out with examples, it is a tradeoff.
>
> But that is exactly what I want - to have full(er) context! The secret
> procedure makes that harder. Of course, there are tradeoffs and some
> details must be withheld - but the first version of RFC (did not read
> the new one yet) was "maximum confidentiality", and that's not good IMO.
> I think the default should be "maximum disclosure, unless it's obviously
> damaging (personal data, etc.) or no-content (insults, slurs, etc.)".
> I.e. I recognize there's no absolute, I just want the balance be different.
>
>
That makes very good sense. I think the process could be optimized, but I
think aiming for maximum disclosure is as problematic as maximum
confidentiality - it ignores the perspective of one party.



> > That is a truism: doing more damage is not fixing anything. However,
> > unless I am mistaken, you yourself put forward the lack of explicit
> > problems as an argument in favour of not doing anything.
>
> Right. So that's one point of discussion - should we do anything at all
> or not. But if we *are* doing something - that's the second point of
> discussion - namely, institute new structure with broad powers in the
> community - we should do it in a way that is least likely to cause damage.
>
>
I wholeheartedly agree.


-- 

WWW: plphp.dk / plind.dk
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15

Re: [PHP-DEV] [RFC] Differentiate op from assign-op in operator overloading

[Sara Golemon]

On Mon, Jan 4, 2016 at 1:39 AM, Nikita Popov  wrote:
> I'd like to provide some context as to why the current implementation works
> as it does.
>
Thanks for the context, Niki.  It makes sense that, with GMP as the
flagship target of operator overloading, stripping away the by-ref
semantics of objects would be appealing.  This way GMP objects just
look like regular numbers.

Except they're not.  Nor are they really objects at this point.  They
have no methods, no properties, they're not instantiated with the new
keyword, and they have by-value semantics (mostly).

That feels really odd to me, that GMP objects, at the moment of their
inception were /designed/ to be non-object objects.  Would this carry
forward to any OOP API we might introduce in the future?  i.e.
$g->add(123);  wouldn't muttate $g, but would return a new instance?

Leaving GMP out of the equation for now (and I think we need to have a
longer discussion about this, but in another thread), I think the
question which remains is: Do we want more non-object objects?
Should, for example, SimpleXMLbe constrained by GMP's goals when
implementing overloaded operators (no, I don't know what this would
look like, it's just a for-instance).

If the answer to that is "No" (which I think it is), then the question
is: Can we modify the do_operation API in a way that allows GMP to
remain psuedo-by-value while still allowing other internal objects
which implement overloading to be more correct?   I think we can.
I'll cobble together a gist of how that might look if there's
tentative buy-in, but I'm pretty sure PHP7's variable model does let
us do that.

-Sara

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

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[Stanislav Malyshev]

Hi!

> It's interesting to note how few people in this thread consider the
> perspective of potential harassed or abused people - instead only
> focusing on how to protect the accused.

We do not discuss it much because it is a) covered in the RFC thus
forming context of the discussion and b) most of it is non-controversial
- we know hurting people is bad, we should not do it, and we should not
accept such behavior in our community. It is *how* we achieve that which
is the question for discussion.

> Quick check: how many times in the history of PHP has someone been
> called out, wrongly, for being abusive or harassing others? If, as seems

There was some amount of "meta" discussions, in which all kinds of
complaints and counter-complaints were voiced, many times. But since we
have no formal mechanism for "accusing" or for determining "wrong", we
can't really know how many of such cases there were.

> to the argument ("we're such a great and tolerant community, we don't
> need this"), this hasn't happened - what's with the paranoia behind
> assuming it will suddenly happen constantly and that people will be
> banned left and right for no reason?

Because unfortunately we have witnessed, in other communities, how
applying such things too hastily and without due consideration can cause
damage. While abuse is undeniably damaging, doing more damage, this time
by ourselves, is not the right way to fix it.

> voting is allowed. Even in the most clearcut case where someone is being
> a complete asshole, you're then either allowing them to continue the
> harassment or ignoring your own point. It's hard to see how either
> option benefits PHP, let alone the abused person.

In most clearcut case where somebody is obviously misbehaving, we have
plenty of people that can revert commits or remove people from ML. That
happened in the past. We do not need a special troika for that.
-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[Stanislav Malyshev]

Hi!

> Yes, I thought it up, hence it's theoretical. If you think that means it
> hasn't happened countless times along those lines, you need to learn how
> to google.

I hope you realize how weak is an argument along the lines of "I am
right, if you don't see it, learn how to google".

> Is there any particular reason you feel the need for arguing strawmen?
> At which point has *anyone* argued for against due process? If you
> cannot point to any such point, would you mind not assuming them?
> 
>  
> 
> I hope that would be going too far for you?
> 
> 
> See above.

As you see, I have assumed exactly the opposite: that you are *not*
against due process. That's what "going too far" means. You are merely
using an argument that proves too much
(https://en.wikipedia.org/wiki/Proving_too_much) - following that
argument, we could conclude that due process is bad. Which is an absurd
conclusion - that's how reductio ad absurdum works.

> Unless you've been through abuse and harassment along the lines
> of 
> http://blog.randi.io/2015/12/31/the-developer-formerly-known-as-freebsdgirl/
> I would suggest you stop assuming what it is like.

I can not stop it since I never started. But what is like, however bad
it is, is not an argument for what we are discussing, since we do not
argue what happened there is good. We argue whether adopting the RFC is
a good way to prevent something like that from happening or reduce its
incidence. Saying "introducing safe mode is not a good way to improve
security" is not the same as saying "we need no security" :)

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

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

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[Peter Lind]

On 5 January 2016 at 19:42, Stanislav Malyshev  wrote:

> Hi!
>
> > It's interesting to note how few people in this thread consider the
> > perspective of potential harassed or abused people - instead only
> > focusing on how to protect the accused.
>
> We do not discuss it much because it is a) covered in the RFC thus
> forming context of the discussion and b) most of it is non-controversial
> - we know hurting people is bad, we should not do it, and we should not
> accept such behavior in our community. It is *how* we achieve that which
> is the question for discussion.
>
>
That is the problem: you cannot discuss how to protect the accused without
having the context of the abused. As you have yourself pointed out with
examples, it is a tradeoff.



> > Quick check: how many times in the history of PHP has someone been
> > called out, wrongly, for being abusive or harassing others? If, as seems
>
> There was some amount of "meta" discussions, in which all kinds of
> complaints and counter-complaints were voiced, many times. But since we
> have no formal mechanism for "accusing" or for determining "wrong", we
> can't really know how many of such cases there were.
>
> > to the argument ("we're such a great and tolerant community, we don't
> > need this"), this hasn't happened - what's with the paranoia behind
> > assuming it will suddenly happen constantly and that people will be
> > banned left and right for no reason?
>
> Because unfortunately we have witnessed, in other communities, how
> applying such things too hastily and without due consideration can cause
> damage. While abuse is undeniably damaging, doing more damage, this time
> by ourselves, is not the right way to fix it.
>
>
That is a truism: doing more damage is not fixing anything. However, unless
I am mistaken, you yourself put forward the lack of explicit problems as an
argument in favour of not doing anything.

A middle way could be - like we're doing now - discuss options that amount
to more than doing nothing (status quo) and less than voting in the worst
possible option.



> > voting is allowed. Even in the most clearcut case where someone is being
> > a complete asshole, you're then either allowing them to continue the
> > harassment or ignoring your own point. It's hard to see how either
> > option benefits PHP, let alone the abused person.
>
> In most clearcut case where somebody is obviously misbehaving, we have
> plenty of people that can revert commits or remove people from ML. That
> happened in the past. We do not need a special troika for that.
>

 Ah, I mistook the idea of using the RFC to handle problems with conduct to
be a general way to deal with things.

-- 

WWW: plphp.dk / plind.dk
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15

Re: [PHP-DEV] Deprecation of the Error Control Operator (@ symbol)

[Sara Golemon]

On Tue, Jan 5, 2016 at 9:37 AM, Andrea Faulds  wrote:
>> How about a global "disable error suppression" setting?  That way a
>> project lead could enforce it for their codebase (and guarantee that
>> devs "aren't lazy"), but PHP doesn't lose its pragmatism?
>
> I don't think that would work out too well. Remember that many projects have
> error handles which convert all errors to exceptions: if you disable @ in
> those projects, wouldn't their code break?
>
Nope.
Supressed errors already reach custom error handlers: https://3v4l.org/TG8aA

-Sara

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

Re: [PHP-DEV] Re: [RFC] [Draft] Adopt Code of Conduct

[Ferenc Kovacs]

>
>
> Additionally, given that this CoC has far reaching consequences, I would
> suggest opening up voting on it's implementation to a wider segment of the
> community eg those currently subscribed to the PHP mailing lists or at
> least those who have recently participated on one.
>
> ~C
>

wouldn't that allow sock puppeting and vote brigading?

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

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[Sara Golemon]

On Tue, Jan 5, 2016 at 10:27 AM, Kevin Smith  wrote:
> Much of the argument in favor of a code of conduct seems to be centered 
> around the desire to send a message to the wider developer world that we’re a 
> welcoming community that doesn’t look kindly on poor treatment of others. If 
> that’s the goal, rather than the goal being to punish or censor people who 
> violate our own values, why do we need a response team with the power to ban?
>
> If a person's treatment of others truly warrants banishment, then as Zeev 
> noted the RFC process is already perfectly suited for that. As far as I’m 
> concerned, the absolute greatest power the response team should be given is 
> the power to issue a censure. If sending a message is the goal, that’ll do it.
>
>
I'll chime in on this, since you and I had a quite pleasant and
productive conversation last night.  I believe we agreed that the
original draft was over-focused on punitive measures and not enough on
low-impact mediation.

I imagine, because I love all you guys (and gals), that the volume of
traffic to a response team would be low to begin with.  I further
imagine, since you're all such a great bunch of lads (and lasses),
that the vast majority of those complaints would be resolvable with
some gentle mediation.  That's a good focus for the CoC, and I would
love to bring us to that point.  (Sorry if you've already addressed
this Anthony, I haven't read your updates yet, it's been a busy
morning).

I said it in a prior email, but I'll repeat it.  I see it like the
security@ list.  A place to send issues that don't necessarily bear
airing in public.  That's good for both the accuser AND the accused.
A tiny layer of discretion to ease what may be a tense issue.

I don't, however, agree that the response team should be entirely
toothless.  As a *last resort*, a (no more than) 7 day ban to act as a
cooling off period isn't "vast sweeping powers", it's a band-aid for a
situation that's gotten out of control.  A situation that demands the
wider community's attention, because it's become unacceptable.  We can
define the limits of these powers (again I've said this in a previous
email).

Worried about abuse of temp-bans?  Don't think a stringent requirement
of justification is enough?  How about the accuser must suffer an
equal ban?  By the time it's come to the point where action must be
taken, the problem has escalated to the point where privacy of the
accused won't be maintainable anyway (due to evidence requirements).
Turn the temp-ban into a cooling off period.  Because honestly, do we
have mustache twirling ne'er-do-wells? Or do we have passionate people
who get worked up into a lather and sometimes cross a line?

As someone who has crossed that line more than once, I hope you'll
trust it's just the latter.

-Sara

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

Re: [PHP-DEV] Deprecation of the Error Control Operator (@ symbol)

[Ferenc Kovacs]

On Tue, Jan 5, 2016 at 6:53 PM, Sara Golemon  wrote:

> On Tue, Jan 5, 2016 at 9:37 AM, Andrea Faulds  wrote:
> >> How about a global "disable error suppression" setting?  That way a
> >> project lead could enforce it for their codebase (and guarantee that
> >> devs "aren't lazy"), but PHP doesn't lose its pragmatism?
> >
> > I don't think that would work out too well. Remember that many projects
> have
> > error handles which convert all errors to exceptions: if you disable @ in
> > those projects, wouldn't their code break?
> >
> Nope.
> Supressed errors already reach custom error handlers:
> https://3v4l.org/TG8aA
>

sure and most projects check the error_reporting() level against the $errno
like in the manual:
if (!(error_reporting() & $errno)) {
// This error code is not included in error_reporting
return;
}

@ changes the error_reporting() level for that particular call, so those
custom error handler won't throw exceptions for the suppressed errors but
when you remove/nop @ their code would throwing stuff left and right.

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

Re: [PHP-DEV] Re: [RFC] [Draft] Adopt Code of Conduct

[Chris Riley]

On 5 January 2016 at 16:15, Anthony Ferrara  wrote:

> All,
>
> On Mon, Jan 4, 2016 at 4:06 PM, Anthony Ferrara 
> wrote:
> > Hey all,
> >
> > I have created a new RFC for the PHP Project to adopt the Contributor
> > Covenant as the official Code of Conduct for the project
> >
> > https://wiki.php.net/rfc/adopt-code-of-conduct
> >
> > Let me know what you think or if there are any concerns
> >
> > Thanks
> >
> > Anthony
>
> In response to significant feedback here and elsewhere, I have
> expanded the text of the RFC significantly. It now includes the text
> of the Contributor Covenant 1.3.0 as well as including verbage about
> updating it requiring an RFC.
>
> I included a vote requirement for course of actions of 4/5 of the CoC team.
>
> I also included content about the "Reasonable Person Test", explicitly
> stating that it shall be assumed that both parties are acting as
> reasonable people until proven otherwise by significant evidence. It
> also stipulates that reporting an incident does not excuse someone
> from the CoC (meaning victims are still bound to follow it, and are
> not excused from proper behavior because of a violation).
>
> I also made it explicit that potential actions should be a last
> resort, and that the CoC team should make every reasonable attempt to
> defuse the situation without having to resort to "punishment".
>
> I also removed the ability to remove commit karma from the team,
> instead including that in the "ban" category (meaning that the CoC
> team is no longer allowed to remove commit karma long-term without the
> action of internals@)
>
> Additionally, I added a line specifying that bans (temporary or
> permanent) should only be used in egregious cases.
>
> I added a section on transparency, Conflict of Interest (though this
> needs expanding) and accountability (giving internals@ the ability to
> "overturn" any action by the CoC team with a vote of 50%+1). I also
> made it explicit that accused people have a right to confidentiality
> as long as no action is taken by the team.
>
> I also added a section on appeals.
>
> Those are the changes to the RFC as it stands. Please review them.
>
>
>
> As to the comments in this thread, I won't reply to every one, but
> here are a few points I'd like to make.
>
> It's been mentioned that we may want to adopt a CoC, but it shouldn't
> "have teeth". I disagree here, as without an enforcement mechanism it
> basically is no different from where we are at today. Saying we should
> act reasonable is fine, but we need a method for what we are to do
> when one of us acts unreasonably. Additionally, as has been stated,
> requiring people to report publicly creates a barrier to entry. Many
> people will simply chose to leave quietly rather than report publicly.
> Simply look at the way people who speak out about harassment are
> treated in public to understand why. The point of the CoC is to create
> a safe place for everyone to contribute, not just those with thick
> skin.
>
> As to why the Contributor Covenant as opposed to another CoC or our
> own custom one, there are two reasons for this. First, it's a standard
> that's been adopted by a number of significant scale projects. Second,
> it saves us from having to bikeshed over every single word of a CoC.
> If there's another standard CoC that we should entertain, I'm happy to
> look at it. But I do not believe that we should create our own.
>
> As far as the conflict resolution process, that I am open to expanding
> or retracting as much as practical. I do think it's important to have,
> but would be happy to take advice from groups like Drupal who have
> done this before.
>
> To those that say this is a solution in search of a problem, it very
> well may be. But that doesn't mean it isn't important to do. You could
> say the same thing about smoke detectors. Even if you've never had a
> fire, that doesn't mean it isn't good practice to install protection
> from one. In this case, we simply do not know if or how many
> contributors we may have lost due to incidents covered by a CoC. Even
> if that number is 0, does that mean it's not worth installing one to
> prevent it in the future?
>
> Thanks,
>
> Anthony
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
I'd suggest we consider using drupals CoC as a model; it has a more
positive tone.

Additionally, given that this CoC has far reaching consequences, I would
suggest opening up voting on it's implementation to a wider segment of the
community eg those currently subscribed to the PHP mailing lists or at
least those who have recently participated on one.

~C

Re: [PHP-DEV] Deprecation of the Error Control Operator (@ symbol)

[Sara Golemon]

On Tue, Jan 5, 2016 at 10:09 AM, Ferenc Kovacs  wrote:
>> > I don't think that would work out too well. Remember that many projects
>> > have
>> > error handles which convert all errors to exceptions: if you disable @
>> > in
>> > those projects, wouldn't their code break?
>> >
>> Nope.
>> Supressed errors already reach custom error handlers:
>> https://3v4l.org/TG8aA
>
> sure and most projects check the error_reporting() level against the $errno
> like in the manual:
> if (!(error_reporting() & $errno)) {
> // This error code is not included in error_reporting
> return;
> }
>
> @ changes the error_reporting() level for that particular call, so those
> custom error handler won't throw exceptions for the suppressed errors but
> when you remove/nop @ their code would throwing stuff left and right.
>
Today I learned...  Okay, def a problem (for a specific set of
circumstances).  And one which makes me more amenable to Ze'ev
declare() suggestion (on a per-request bases, not per-file) as anyone
modifying a project's codebase for testing can also modify it to
suppress those exceptions as needed and/or just not enable the custom
error handler.

-Sara

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

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[Kevin Smith]

Much of the argument in favor of a code of conduct seems to be centered around 
the desire to send a message to the wider developer world that we’re a 
welcoming community that doesn’t look kindly on poor treatment of others. If 
that’s the goal, rather than the goal being to punish or censor people who 
violate our own values, why do we need a response team with the power to ban?

If a person's treatment of others truly warrants banishment, then as Zeev noted 
the RFC process is already perfectly suited for that. As far as I’m concerned, 
the absolute greatest power the response team should be given is the power to 
issue a censure. If sending a message is the goal, that’ll do it.


Kevin Smith
http://gohearsay.com

Re: [PHP-DEV] Re: [RFC] [Draft] Adopt Code of Conduct

[Chris Riley]

On Tue, 5 Jan 2016, 18:20 Ferenc Kovacs  wrote:

>
>> Additionally, given that this CoC has far reaching consequences, I would
>> suggest opening up voting on it's implementation to a wider segment of the
>> community eg those currently subscribed to the PHP mailing lists or at
>> least those who have recently participated on one.
>>
>> ~C
>>
>
> wouldn't that allow sock puppeting and vote brigading?
>
> --
> Ferenc Kovács
> @Tyr43l - http://tyrael.hu
>

And that won't happen on this rfc regardless?

>

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[Anthony Ferrara]

Rowan,

On Tue, Jan 5, 2016 at 2:16 PM, Rowan Collins  wrote:
> Paul M. Jones wrote on 05/01/2016 16:03:
>>
>> It's a*political*  action designed with a*political*  intent
>
>
> Please stop assuming that everybody has a hidden agenda at odds with their
> public statements, and claiming that you somehow know that the negative
> possibilities of this policy are deliberately in service of its secret aim,
> rather than unintended consequences of its stated aim.
>
> If you dislike the details of this proposal, that is fine, and you can
> explain what you don't like about it, and what you would prefer instead -
> e.g. a "be nice" policy without explicit teeth, or total anarchy and the
> right to insult, threaten, and bully whoever you choose because you honestly
> believe that "free speech" trumps all other moral and pragmatic
> considerations.
>
> Bear in mind you will be expected to defend that position, and that people
> have the right to disagree with you, and attempt to find common ground and
> compromises. That's how conversations work.
>
> If all you're doing is trolling the group because you think being rude on a
> thread about good conduct is funny, please go do it on 4chan or reddit or
> something.

Paul isn't trolling. He is simply passionate about it. While I do
believe he can be more constructive with how he interacts in this
specific thread, he definitely isn't trolling (trying to cause drama
for drama's sake). We should be careful about that term and use it
appropriately.

Anthony

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

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[Rowan Collins]

Anthony Ferrara wrote on 05/01/2016 19:20:

Paul isn't trolling. He is simply passionate about it. While I do
believe he can be more constructive with how he interacts in this
specific thread, he definitely isn't trolling (trying to cause drama
for drama's sake). We should be careful about that term and use it
appropriately.


Indeed, an accusation of trolling can be incendiary in itself, and I 
shouldn't have included it. Thank you for calling me out on it.


Paul, I apologise for that, it was hypocritical of me in a post asking 
you to - in the words of Wikipedia's famous policy - "Assume Good Faith".


My main point, in a nutshell, is that insinuations that the proposed CoC 
is *designed* to give arbitrary power to a small group of people are 
disingenuous. Drawing attention to the *risk* of power concentrating in 
a small group of people is a reasonable line of discussion.


Regards,
--
Rowan Collins
[IMSoP]

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

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[François Laupretre]

Hi,

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

One thing I really like about the covenant Anthony is proposing (besides
it
being the same as the one a bunch of other projects are
using) is that it actually is pretty short, considering what it is.
The English version fits on one screen on my laptop.

I actually find that a bad thing.  As I think the Voting RFC proved (IMHO
beyond a reasonable doubt) - what's not clearly defined in the text, may
evolve in unpredictable directions in the future.

Specifically, the Contributor Covenant has text which in my opinion, is
either too open for interpretation or needs to be narrowed down - e.g.
'Personal Attacks' and even more so 'Other unethical or unprofessional
conduct'.  What one may find a legitimate part of a heated discussion -
another may find as a personal attack.  What one may consider perfectly
fine - another may find completely unethical.  These are subjective matters
and giving a group of five (or seven, or nine) people judicial power over
them is very problematic.

While I understand the position that even though it's "a solution waiting
for a problem" - proactively providing such a CoC makes sense - I think the
open-endedness and the risk of bad things happening as a result of it are
far greater than any positives.

I would focus on creating as-clear-cut-as-possible CoC (probably a trimmed
down version of the Contributor Covenant), but would leave the 'teeth' part
(i.e. the council part and any sanctions) out.

In the very extreme situations where someone truly needs to be banned or
otherwise sanctioned, any one of us can propose an RFC to do it.  I would
require a 2/3 majority and probably no less than X voters voting in favor of
the ban, given the far-reaching implications (X being at least several dozen
people IMHO).  Personally, I would advise to never issue permanent bans -
people do sometimes change.  People get second chances for doing much worse
things;  I'd go for a 1yr or at most 2yr bans (again, in exceptional cases
only).

My 2c.

Zeev
+1. The proposed CoC is too vague for a multi-cultural environment like 
ours. Reference to ethics, for example, is subjective by nature. But I'm 
OK for a more precise text that everybody must explicitely approve 
before getting any karma.


But I am opposed to any form of law enforcement board. I understand it 
ensures privacy but my feeling is that we don't need privacy here, and 
we never needed such a mechanism during 20 years. Most questionable 
messages are published on the mailing list. If someone receives an 
offending private mail or is victim of harassment in any other way, he 
can just publish it on the list and everyone will judge if it is 
offending or not. Then, if we need to consider banning someone, anybody 
can create a specific RFC for this, but it is an extreme case that, 
fortunately, has a very low probability..


Regards

François

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

[PHP-DEV] VCS Account Request: bof

[Patrick Schaaf]

Help with mirror (infrastructure!) maintenance. Hannes Magnusson indicated 
I\d need a GIT account for that, Daniel Brown thinks I\ll need web 
karma.


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

[PHP-DEV] Re: [RFC] Normalize token_get_all() output (with flag)

[Sara Golemon]

On Mon, Jan 4, 2016 at 2:56 PM, Sara Golemon  wrote:
> https://wiki.php.net/rfc/token-get-always-tokens
>
A suggestion from a co-worker who's worried about seeing patterns like:

case ($t['token']) {
  case T_PAAMAYIM_NEKUDOTAYIM:
// do something
   break;
  case ord(';'):
// do something else
break;
}

I see three options to remediate this:
1) We could offer constants like: T_SEMICOLON (or T_ASCII_SEMICOLON)
defined to that character's ordinal value. (using unicode names)
2) Make the token field be the character value (for single-character
tokens) instead of the ordinal.
3) Add an additional field such that you have Array ( ['id'] => 59,
['token'] => ';', ['text'] => ';', ['line'] => 1 )  'id' would always
be integer, while 'token' would be int or single-char.

I don't like 3 as it's wasteful and needlessly duplicative.  1 feels a
bit over-engineered and actually hurts readability.  2 feels like a
nice compromise and matches how our rules end up looking in the parser
anyway (since C treats single characters as ordinals already).

-Sara

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

Re: [PHP-DEV] Deprecation of the Error Control Operator (@ symbol)

[Aaron Piotrowski]

> On Jan 5, 2016, at 12:22 PM, Sara Golemon  wrote:
> 
> On Tue, Jan 5, 2016 at 10:09 AM, Ferenc Kovacs  wrote:
 I don't think that would work out too well. Remember that many projects
 have
 error handles which convert all errors to exceptions: if you disable @
 in
 those projects, wouldn't their code break?
 
>>> Nope.
>>> Supressed errors already reach custom error handlers:
>>> https://3v4l.org/TG8aA
>> 
>> sure and most projects check the error_reporting() level against the $errno
>> like in the manual:
>>if (!(error_reporting() & $errno)) {
>>// This error code is not included in error_reporting
>>return;
>>}
>> 
>> @ changes the error_reporting() level for that particular call, so those
>> custom error handler won't throw exceptions for the suppressed errors but
>> when you remove/nop @ their code would throwing stuff left and right.
>> 
> Today I learned...  Okay, def a problem (for a specific set of
> circumstances).  And one which makes me more amenable to Ze'ev
> declare() suggestion (on a per-request bases, not per-file) as anyone
> modifying a project's codebase for testing can also modify it to
> suppress those exceptions as needed and/or just not enable the custom
> error handler.
> 

Exactly. There’s no need for a new ini setting, since an error handler can be 
written that ignores the current error level and throws an exception or does 
whatever the coder wants.

Abuse is the only real problem with the @ operator. Coders use it in place of 
proper state or error checking. However, there are legitimate uses such as with 
fwrite, fopen, stream_select, etc. that Grzegorz Zdanowski and I pointed out. 
Before anything can be done with the @ operator, changes will need to be made 
to remove warnings for conditions that the code has no way of checking prior to 
calling these functions. Setting a custom error handler before calling these 
functions and removing the error handler afterwards is a clunky solution. Any 
proposal to remove the @ operator needs to address how functions issuing 
unavoidable warnings will be changed.

Aaron Piotrowski
https://trowski.com
@trowski2002
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Re: [RFC] [Draft] Adopt Code of Conduct

[Zeev Suraski]

> -Original Message-
> From: Anthony Ferrara [mailto:ircmax...@gmail.com]
> Sent: Tuesday, January 05, 2016 6:16 PM
> To: internals@lists.php.net
> Subject: [PHP-DEV] Re: [RFC] [Draft] Adopt Code of Conduct
>
> As to the comments in this thread, I won't reply to every one, but here
> are a
> few points I'd like to make.

Anthony,

Thanks - I think the new draft looks much better and addresses much of my
feedback.  I still think it puts too much emphasis on the mechanics and
punitive actions, see below.

>
> It's been mentioned that we may want to adopt a CoC, but it shouldn't
> "have teeth". I disagree here, as without an enforcement mechanism it
> basically is no different from where we are at today.

I think it's actually very different.  Today we have no CoC.  Stating a
direction, a vision for the community - can go a very long way.  To
illustrate, I suspect most of us are law-abiding citizens not because we're
afraid of being thrown to jail - but rather, because we value the rule of
law and know that abiding the law is the Right Thing to do.  If we simply
adopt a CoC without adding teeth to it, we'd certainly not be the first
project to do so.

> Saying we should act
> reasonable is fine, but we need a method for what we are to do when one of
> us acts unreasonably.  Additionally, as has been stated, requiring people
> to
> report publicly creates a barrier to entry. Many people will simply chose
> to
> leave quietly rather than report publicly.
> Simply look at the way people who speak out about harassment are treated
> in public to understand why. The point of the CoC is to create a safe
> place
> for everyone to contribute, not just those with thick skin.

My main concern is/was that we're venturing into areas where we have
absolutely no experience and completely inadequate training.  We are not
legislators nor lawyers;  We've demonstrated more than once that we're not
very good at establishing 'written law' for far simpler and non-ambiguous
things, failing to predict all possible scenarios of the future.  The fact
we need to borrow definitions from Criminal Law should be an indicator that
we're probably venturing in the wrong direction here.  The system
responsible for implementing the law, as we all know, is complex and with
countless checks and balances - and as I think we all know, it is also
subjective, completely open for interpretation and with a very strong human
element - and consequently frequently fails.  My concern is that we're
trying to sketch a simplistic system which would fail us in unpredictable
ways in the future, when the rubber meets the road.

And with all that said, it seems to be much less of an issue with the
updated RFC, given the reduced power of the CoC team and the changed
'spirit' of it.  I do need to review the RFC more closely though.

> As to why the Contributor Covenant as opposed to another CoC or our own
> custom one, there are two reasons for this. First, it's a standard that's
> been
> adopted by a number of significant scale projects. Second, it saves us
> from
> having to bikeshed over every single word of a CoC.
> If there's another standard CoC that we should entertain, I'm happy to
> look
> at it. But I do not believe that we should create our own.

I think the Contributor Covenant is problematic when used as a law, as
opposed to guidelines - because it's way too open ended.
But again - with the substantial changes to the RFC, I think it's less of an
issue.

Thanks again for the efforts on this!

Zeev

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

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[Andrea Faulds]

Hi Michael,

Michael Cullum wrote:

4) What voting method would be used to choose the 5 people? Single
Transferable Vote is a much better system for this kind of thing,
especially considering the nature of ensuring a balance of opinion on the
committee. The one issue with this being it's not supported on the wiki I
assume?


Another option is simply multiple-choice voting: i.e. allow a voter to 
vote for multiple candidates, then we simply make the five members be 
the five people with the most votes.


This has the benefit that it is a simple and easy-to-understand process. 
I also imagine this would be less difficult to get working on the wiki. 
There's probably issues with it, though, and I wouldn't be the best 
person to list them.


Thanks.
--
Andrea Faulds
https://ajf.me/

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

[PHP-DEV] Re: [RFC] Normalize token_get_all() output (with flag)

[Andrea Faulds]

Hi Sara,

Sara Golemon wrote:

I swear, 2016 isn't going to be "An RFC per day" year, but...

https://wiki.php.net/rfc/token-get-always-tokens

This should be pretty non-controversial.  I hope?


This is more of a side-note, but maybe it's worth bringing up. Since 
token_get_all gives an array with subarrays of a regular structure, 
might it be worthwhile returning an array of objects instead? It would 
probably reduce memory usage (assuming they're objects of a Token class 
or something, not StdClass), but I don't know if it's that useful.


Thoughts?
--
Andrea Faulds
https://ajf.me/

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

Re: [PHP-DEV] Re: [RFC] [Draft] Adopt Code of Conduct

[Andrea Faulds]

Hi Chris,

Chris Riley wrote:

On Tue, 5 Jan 2016, 18:20 Ferenc Kovacs  wrote:




Additionally, given that this CoC has far reaching consequences, I would
suggest opening up voting on it's implementation to a wider segment of the
community eg those currently subscribed to the PHP mailing lists or at
least those who have recently participated on one.

~C



wouldn't that allow sock puppeting and vote brigading?

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



And that won't happen on this rfc regardless?


At least for sockpuppeting, not without obvious abuse of power it can't. 
Every new VCS account request is posted to the mailing list. New 
accounts can't just appear out of nowhere without it being obvious, so 
sockpuppeting (without long-established sockpuppets) isn't possible.


Vote brigading *could* be an issue, but you can only do that if you have 
a large "brigade" of people with PHP VCS accounts. I don't think there 
is one.


However, opening the vote up to a wider audience makes these two 
possibilites more likely.


Thanks.
--
Andrea Faulds
https://ajf.me/

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

Re: [PHP-DEV] Re: [RFC] [Draft] Adopt Code of Conduct

[Stanislav Malyshev]

Hi!

> In response to significant feedback here and elsewhere, I have
> expanded the text of the RFC significantly. It now includes the text
> of the Contributor Covenant 1.3.0 as well as including verbage about
> updating it requiring an RFC.

Thanks for improving the RFC. It is already much better than the initial
variant, though I think more improvement is needed. As I wrote in
previous emails, I'd like mode of what we want than what we hate. We
already seen example from Drupal, here's one from Python:

https://wiki.python.org/psf/CodeOfConduct

I agree with having specific point of contact to turn to is beneficial
and it should probably be featured on the same page as the text above. I
am not sure I understand why list should be unarchived - while I see why
*public* archive is not good, why not have private archive accessible to
the members? After all, any member can archive all the emails anyway
(and people with accounts like gmail probably routinely keep mails for
years without deleting them). But having the established one avoids the
situation where there's a problem with one member of the list and it
turns to "she said, he said" situation with no proof of anything.

> I included a vote requirement for course of actions of 4/5 of the CoC team.

Good!

Additionally, I would propose naming this team something like Mediation
Team or Conflict Resolution Team, to emphasize that its primary role to
find the best resolution of issues and not to bash people over the head
with codes. Bikeshedding on the name along these lines is welcome :)

> This Code of Conduct applies both within project spaces and in public
spaces when an individual is representing the project or its community.

I think this is way too broad. "individual is representing the project
or its community" can be construed to mean basically anything - if a
person is known in the community, any of their actions, even without
relation to the community functions, can always be construed as
"representing", especially by people with an ax to grind. We'd get
people complaining "how could prominent member of this project vote for
that vile politician X" and "how could prominent member of this
community support that awful law Y" and we definitely not want to go there.

> Process For Incidents

I think the process should be amended to emphasize that the first course
of action for the team should be to try and find amicable resolution of
the issue (I imagine there are many established mediation techniques
that can be applied and referenced, we're not exactly pioneers here :)
and only when it proves futile (or misconduct is so egregious that it is
obvious it is too late for mediation) the team would take further
action. I.e. one does not need a vote to help diffuse the conflict.

> I also included content about the "Reasonable Person Test", explicitly
> stating that it shall be assumed that both parties are acting as
> reasonable people until proven otherwise by significant evidence. It

That is good. I think the principle of assuming good faith leads to
better results.

> I also made it explicit that potential actions should be a last
> resort, and that the CoC team should make every reasonable attempt to
> defuse the situation without having to resort to "punishment".

Excellent!

> Either party may appeal an action by raising the concern to
intern...@php.net.

That would be impossible if one of the parties is banned from internals.

> All incidents are to be kept in the strictest form of confidentiality

I still think the secrecy bias is unhealthy. I remember how much
controversy was produces by the supposedly private discussions of
certain technical questions and RFCs. Imagine how much more heat would
be generated if the discussion in question has a conflict as a starting
point. The potential for toxic suspicions and distrust is enormous.

> Additionally, I added a line specifying that bans (temporary or
> permanent) should only be used in egregious cases.

I'm not sure I still comfortable with notion of these bans, especially
the one which bans somebody for the duration of RFC discussion in which
their case is discussed.

> I added a section on transparency, Conflict of Interest (though this
> needs expanding) and accountability (giving internals@ the ability to
> "overturn" any action by the CoC team with a vote of 50%+1). I also
> made it explicit that accused people have a right to confidentiality
> as long as no action is taken by the team.

I am a big fan of transparency, but here in particular I'm not sure that
every mediation attempt should be indeed reported. Maybe if no further
escalation was required, less publicity is better. We need to be careful
here, as many things could be resolved in private more efficiently if
public displays and egos are less involved :) This is another thing
where over-legislation is bad, as there's a lot of common sense needed
and you can't legislate that.

> own custom one, there are two reasons for this. First, 

Re: [PHP-DEV] Re: [RFC] Normalize token_get_all() output (with flag)

[Andrea Faulds]

Hi Sara,

Sara Golemon wrote:

On Tue, Jan 5, 2016 at 12:52 PM, Andrea Faulds  wrote:

This is more of a side-note, but maybe it's worth bringing up. Since
token_get_all gives an array with subarrays of a regular structure, might it
be worthwhile returning an array of objects instead? It would probably
reduce memory usage (assuming they're objects of a Token class or something,
not StdClass), but I don't know if it's that useful.


Is the internal memory usage of (new stdClass) actually less than
(array())?  I know array changed a lot with PHP7, and that the kind of
array we're talking about here is a mixed (which would be the least
efficient), but I don't have the numbers to hand.


No, a StdClass would consume more memory than an array, because it has a 
hashtable plus object overhead.


But having a specific token class would much consume less, since there's 
no hashtable overhead for defined properties:


https://gist.github.com/nikic/5015323

I believe it's even better in PHP 7.


To your question, I'm cool either way.  Though if memory/efficiency is
a concern, returning an iterator would be even better, especially on
large files.  Though I think that's beyond the scope of this
particular RFC.


Memory probably doesn't matter, this was mostly a "what if" suggestion.



Maybe I should keep up my "1 RFC per day" run and suggest
TOKEN_ITERATOR as yet another flag   Maybe not.  My inbox hurts.


I know first-hand what making too many RFCs can do to you, so I wouldn't 
recommend it.


Thanks! :)
--
Andrea Faulds
https://ajf.me/

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

Re: [PHP-DEV] Re: [RFC] [Draft] Adopt Code of Conduct

[Stas Malyshev]

Hi!

> > own custom one, there are two reasons for this. First, it's a standard
> > that's been adopted by a number of significant scale projects. Second,
>
> I completely disagree that Contributor Covenant's text is any kind of
> "standard". I've seen a number of CoCs, and it's not the worst (though
> their homepage is... meh) but also not the best, and certainly not only.

Here are couple more:
Django: https://www.djangoproject.com/conduct/
FreeBSD: https://www.freebsd.org/internal/code-of-conduct.html

I think all those have several common threads:
- more space spent on good conduct than bad conduct
- advice on how to resolve conflicts without escalation
- clear guidelines for reporting problems
- specific one for the project, not a prefabricated copy

Comparing this one to the Covenant one, I clearly think any of those
examples is superior. Is reflects specific project, is helpful, is
positive, and looks like is is written by actual people, not copied
from somewhere because we need to have something.

I think that if we think having CoC is important, then we should have
one that is actually helpful and positive, and not a cookie-cutter
one. And if it's not important enough for us to spend some time on
formulating it, then maybe we don't need it that much? :)

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

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[Bishop Bettini]

HI Anthony,

On Mon, Jan 4, 2016 at 4:37 PM, Bishop Bettini  wrote:

> On Mon, Jan 4, 2016 at 4:06 PM, Anthony Ferrara 
> wrote:
>
>>
>> I have created a new RFC for the PHP Project to adopt the Contributor
>> Covenant as the official Code of Conduct for the project
>>
>> https://wiki.php.net/rfc/adopt-code-of-conduct
>>
>> Let me know what you think or if there are any concerns
>>
>
> Thanks for bringing this to the table, Anthony.  I am +1 because, while
> we're diverse on some axes, we are startlingly alike in others
> .
>

I remain committed to the RFC ideal, but the arguments presented have
swayed me: I cannot support the RFC as written in v0.3. Generally, I reject
language condensing authority to a small subset of individuals and granting
rights to act on their limited opinion. Specifically, the proposed text of
paragraphs 4, 5, 7, and 9 do just that. I am happy to discuss in detail,
but honestly I don't think that will move us closer to consensus.

I think simplification is needed. Let's start with our values before we
start talking about a protocol for accusations. After all, does it matter
how we deal with accusations if we can't agree on core values?

And on that note, I'd like to suggest the Code Manifesto as a starting
point for our values statement: http://codemanifesto.com/

Sincerely,
bishop

[PHP-DEV] Fwd: [PHP Wiki] Your DokuWiki password

[Bryan Hoffpauir]

Good Day!  I'm a new member of the PHP Community Wiki and I'd like to have
my account updated so that I might edit my profile and update my password.

My username is specified below (and my sig has links to my blog and
LinkedIn profile.  I'm a multi-decade experienced PHP developer / architect
/ team leader most recently working with Zend Framework, Zend Server, and
Magento systems.

I'm not 100% sure where I might be able to contribute immediately, but I'd
love to see where there is need for assistance and figure out how I might
be able to help.  Eventually, I'd like to be able to demonstrate my sincere
interest in growing the PHP community and helping my fellow developers
however I can so that I might be considered worthy of the ability to
participate in the dialogue and vote in community RFC elections.

Sincerely,

Bryan "BJ" Hoffpauir, Jr.
beejh...@gmail.com

Twitter: https://twitter.com/beejhuff
Blog: http://innovez.blogspot.com
LinkedIn: https://linkedin.com/in/bjhofpauir

-- Forwarded message --
From: 
Date: Tue, Jan 5, 2016 at 8:19 PM
Subject: [PHP Wiki] Your DokuWiki password
To: Bryan BJ 


Hi Bryan "BJ" Hoffpauir!

Here is your userdata for PHP Wiki at https://wiki.php.net/

Login: beejhuff


--
This mail was generated by DokuWiki at
https://wiki.php.net/

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[Joe Watkins]

Morning internalz,

I'm going to keep it simple, because I'm sure everybody is getting a
bit bored ...

I object to the idea that we should try to limit "offence" ... it's not
quantifiable, and it doesn't matter whatever, I'm offended by all sorts of
things ... so what ...

I can see nothing that is disagreeable in the idea other than this.

If this sentence were changed:

>  Project maintainers have the right and responsibility to remove,
edit, or reject comments, commits, code, wiki edits, issues, and other
contributions that are not aligned to this Code of Conduct,
>  or to ban temporarily or permanently any contributor for other
behaviors that they deem inappropriate, threatening, offensive, or harmful.

   To

> Project maintainers have the right and responsibility to remove,
edit, or reject comments, commits, code, wiki edits, issues and other
contributions, as well as imposing temporary or permanent bans on any
contributor that
> persistently violates our code of conduct.

   And, the final code of conduct were more detailed about unacceptable
behaviour, rather than trying to use blanket terms like "inappropriate" or
"offensive", then I'd be happy to +1 it ... I will not +1 it while it tries
to limit offence, because that's silly, or uses blanket terms that make it
unenforceable.

   So that's me, +1 on the idea, not so much on the text for the code of
conduct ...

Cheers
Joe


On Tue, Jan 5, 2016 at 10:30 PM, Paul M. Jones  wrote:

>
> > On Jan 5, 2016, at 16:21, Nate Abele  wrote:
> >
> > Hi Rowan,
> >
> > I don’t presume to speak for Paul, but I don’t think the point is that
> any particular person involved in this discussion is presumed to have a
> political intent, rather that CoCs themselves (the Contributor Covenant in
> particular), and the people typically agitating for them, come from a place
> of hyper-politicization.
>
> Yes, that is an accurate summary of my position.
>
>
> --
> Paul M. Jones
> pmjone...@gmail.com
> http://paul-m-jones.com
>
> Modernizing Legacy Applications in PHP
> https://leanpub.com/mlaphp
>
> Solving the N+1 Problem in PHP
> https://leanpub.com/sn1php
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Re: [RFC] [Draft] Adopt Code of Conduct

[Stanislav Malyshev]

Hi!

>> True, but as Larry said, either side is problematic. Too loose of a
>> CoC with no enforcement and nothing really was changed from today
>> considering we already have the post that Rasmus made 6-7 years ago.

That implies we do *need* change from situation today. But so far I
didn't see anybody claiming situation today is problematic (not in terms
"not having CoC makes us look uncool and we want to be cool" but in
terms of "something bad is happening right now and we need to take
action to stop it".). Now, I have nothing against looking cool, and if
we can make the community look cooler/safer/warmer/welcomer/more
unicorns and hellokitties with no downsides - sure, why not? The part
that is worrysome for me is the one with downsides, namely "enforcement".

> Perhaps there's a path to compromise here though.  A CoC plus a
> Response Team *without* authority for any punitive action would be a
> step forward.  We don't have to solve every problem right up front, we
> can start with:

I think if we would talk about moderation/mediation team that would try
to resolve a conflict and in a complicated cases - like irresolvable
conflict which makes collaboration impossible - prepare an impartial
summary of the issue and let the community take an action, and maybe be
able to alert necessary people (or even have such people as members) in
case urgent action - like emergency block to stop publishing sensitive
information, etc. - is needed, I would have no problem with that.
I had numerous instances in the past where skillful third-party
mediation allowed resolving differences and pave way for cooperation. So
having people that can do that and are publicly known address for doing
this is a good thing to me. If we lose the punitive focus and have more
"what we want to do and what should happen" and less "what should not
happen and how badly we'll punish you", it would be much better.

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

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

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[Paul M. Jones]

> On Jan 5, 2016, at 15:51, Chase Peeler  wrote:
> 
> While overall I tend to agree with Paul on the concept of a CoC, I don't
> think that precludes the ability to offer suggestions. It's to everyone's
> advantage to make sure that if we do adopt a CoC, we adopt the best one
> possible.
> 
> Obviously one of the biggest fears is unjust treatment of the accused. The
> thing that is most likely to lead to that would be pre-existing personal
> biases towards the accused (or in favor of the accuser) by a member of the
> committee. Why not require that at least one member come from outside the
> PHP community all together. I don't know how feasible that really is, but
> assuming it is, it's probably the best way to ensure that there is at least
> one person that is more likely to be as unbiased as possible.
> 
> That member could be voted on like all the other members, or, due to the
> fact that voters are hopefully less familiar with such candidates, be
> appointed by the elected members of the committee.
> 
> Obviously it's not perfect and still allows the possibility of abuse, but
> you reach the point where such abuses almost require a coordinated
> conspiracy.

If you're dead set on this, why have "appointed" members at all?  Pick randomly 
from the pool of voters, one set of members assigned on a per-accusation basis, 
disallow further service until everyone has been chosen once, then reset the 
counter.

Having said that, a Code of Conduct in *any* form is going to be abused, 
*especially* this one, which I continue to maintain is primarily political in 
nature, fascist in practice, and utterly contemptible.  Larry's "conflict 
resolution" document, while still not that great, is orders of magnitude better 
than this RFC. It at least leads in the direction of people solving their own 
problems, rather than appealing to amenable authority and thus remaining 
dependents on it for all time.



-- 
Paul M. Jones
pmjone...@gmail.com
http://paul-m-jones.com

Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp

Solving the N+1 Problem in PHP
https://leanpub.com/sn1php



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

[PHP-DEV] Re: [RFC] [Draft] Adopt Code of Conduct

[Nate Abele]

Hi Rowan,  

I don’t presume to speak for Paul, but I don’t think the point is that any 
particular person involved in this discussion is presumed to have a political 
intent, rather that CoCs themselves (the Contributor Covenant in particular), 
and the people typically agitating for them, come from a place of 
hyper-politicization.

Exhibit A: 
https://github.com/CoralineAda/contributor_covenant/commit/0e927bc01614d6b0de021a314dbe95e7dfcc7bb9#diff-eacf331f0ffc35d4b482f1d15a887d3bL17

Exhibit B: https://archive.is/dgilk (the threatening language at the end is 
particularly chilling)

I think most reasonable people can agree that these kinds of derailing 
conversations are far more toxic than any knock-on effects of not having a CoC 
in the first place.


- Nate

Re: [PHP-DEV] Re: [RFC] [Draft] Adopt Code of Conduct

[Ferenc Kovacs]

On Tue, Jan 5, 2016 at 10:00 PM, Andrea Faulds  wrote:

> Hi Chris,
>
>
> Chris Riley wrote:
>
>> On Tue, 5 Jan 2016, 18:20 Ferenc Kovacs  wrote:
>>
>>
>>> Additionally, given that this CoC has far reaching consequences, I would
 suggest opening up voting on it's implementation to a wider segment of
 the
 community eg those currently subscribed to the PHP mailing lists or at
 least those who have recently participated on one.

 ~C


>>> wouldn't that allow sock puppeting and vote brigading?
>>>
>>> --
>>> Ferenc Kovács
>>> @Tyr43l - http://tyrael.hu
>>>
>>>
>> And that won't happen on this rfc regardless?
>>
>
> At least for sockpuppeting, not without obvious abuse of power it can't.
> Every new VCS account request is posted to the mailing list. New accounts
> can't just appear out of nowhere without it being obvious, so sockpuppeting
> (without long-established sockpuppets) isn't possible.
>
> Vote brigading *could* be an issue, but you can only do that if you have a
> large "brigade" of people with PHP VCS accounts. I don't think there is one.
>
> However, opening the vote up to a wider audience makes these two
> possibilites more likely.
>
>
I was replying to the suggestion on allowing every mailing list
subscriber/participant to have a vote, that would indeed allow
sockpuppeting and vote brigading, that was my issue with it.

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

Re: [PHP-DEV] Re: [RFC] [Draft] Adopt Code of Conduct

[Stanislav Malyshev]

Hi!

>> True, but as Larry said, either side is problematic. Too loose of a
>> CoC with no enforcement and nothing really was changed from today
>> considering we already have the post that Rasmus made 6-7 years ago.

That implies we do *need* change from situation today. But so far I
didn't see anybody claiming situation today is problematic (not in terms
"not having CoC makes us look uncool and we want to be cool" but in
terms of "something bad is happening right now and we need to take
action to stop it".). Now, I have nothing against looking cool, and if
we can make the community look cooler/safer/warmer/welcomer/more
unicorns and hellokitties with no downsides - sure, why not? The part
that is worrysome for me is the one with downsides, namely "enforcement".

> Perhaps there's a path to compromise here though.  A CoC plus a
> Response Team *without* authority for any punitive action would be a
> step forward.  We don't have to solve every problem right up front, we
> can start with:

I think if we would talk about moderation/mediation team that would try
to resolve a conflict and in a complicated cases - like irresolvable
conflict which makes collaboration impossible - prepare an impartial
summary of the issue and let the community take an action, and maybe be
able to alert necessary people (or even have such people as members) in
case urgent action - like emergency block to stop publishing sensitive
information, etc. - is needed, I would have no problem with that.
I had numerous instances in the past where skillful third-party
mediation allowed resolving differences and pave way for cooperation. So
having people that can do that and are publicly known address for doing
this is a good thing to me. If we lose the punitive focus and have more
"what we want to do and what should happen" and less "what should not
happen and how badly we'll punish you", it would be much better.

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

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

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[Bishop Bettini]

On Mon, Jan 4, 2016 at 10:47 PM, Paul M. Jones  wrote:

>
> > On Jan 4, 2016, at 21:22, Bishop Bettini  wrote:
> >
> > Every long standing collaborative system adopts, uses, and sheds rules
> of conduct to suit its real and perceived challenges.
>
> Including the one headed by Linus Torvalds, right? (/me rolls eyes)
>

Yes, even there.  The system *adopted* Linus as its benevolent dictator and
it *continues to use* that model.  At some point, those rules *will end*.

As far as I know, PHP has no formal governance document, but operates
informally like a meritocratic cathedral
.  Anthony's CoC
addresses one component of such a document, and in my opinion it's good for
us to formalize that.  (See also the PR triage RFC
, which discusses how external
contributions will be handled.)

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[Paul M. Jones]

> On Jan 5, 2016, at 16:21, Nate Abele  wrote:
> 
> Hi Rowan,  
> 
> I don’t presume to speak for Paul, but I don’t think the point is that any 
> particular person involved in this discussion is presumed to have a political 
> intent, rather that CoCs themselves (the Contributor Covenant in particular), 
> and the people typically agitating for them, come from a place of 
> hyper-politicization.

Yes, that is an accurate summary of my position.


-- 
Paul M. Jones
pmjone...@gmail.com
http://paul-m-jones.com

Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp

Solving the N+1 Problem in PHP
https://leanpub.com/sn1php



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

Re: [PHP-DEV] Re: [RFC] [Draft] Adopt Code of Conduct

[Ferenc Kovacs]

On Tue, Jan 5, 2016 at 11:13 PM, Stanislav Malyshev 
wrote:

> Hi!
>
> >> True, but as Larry said, either side is problematic. Too loose of a
> >> CoC with no enforcement and nothing really was changed from today
> >> considering we already have the post that Rasmus made 6-7 years ago.
>
> That implies we do *need* change from situation today. But so far I
> didn't see anybody claiming situation today is problematic (not in terms
> "not having CoC makes us look uncool and we want to be cool" but in
> terms of "something bad is happening right now and we need to take
> action to stop it".). Now, I have nothing against looking cool, and if
> we can make the community look cooler/safer/warmer/welcomer/more
> unicorns and hellokitties with no downsides - sure, why not? The part
> that is worrysome for me is the one with downsides, namely "enforcement".
>
>
having a CoC is not just a cool shiny thing, it is like having an emergency
plan, it doesn't matter much until you need one, and some people are more
comfortable knowing that there is one ready.
everybody start without one, and usually it is better to prepare it
beforehand than after the first real need for it, and coming up with one
while going through the emergency is asking for trouble.
currently we also have no way of knowing how many people are actually
uncomfortable/leaving because we don't have one.


> > Perhaps there's a path to compromise here though.  A CoC plus a
> > Response Team *without* authority for any punitive action would be a
> > step forward.  We don't have to solve every problem right up front, we
> > can start with:
>
>
that something which resonates with what Sara said and similar in nature
what we do with security@, point of contact, with trustworthy people
experienced on the topic and without any additional privileges apart of
being able to seeing the reports and being able to discuss the reported
problem and escalate if necessary.


> I think if we would talk about moderation/mediation team that would try
> to resolve a conflict and in a complicated cases - like irresolvable
> conflict which makes collaboration impossible - prepare an impartial
> summary of the issue and let the community take an action, and maybe be
> able to alert necessary people (or even have such people as members) in
> case urgent action - like emergency block to stop publishing sensitive
> information, etc. - is needed, I would have no problem with that.
>

that could be a good compromise, I suppose we could cover most of the stuff
which could have immediate actions with having somebody with web/* karma,
somebody with php-src(preferable also including Zend/*) and somebody from
the systems@ team.


> I had numerous instances in the past where skillful third-party
> mediation allowed resolving differences and pave way for cooperation. So
> having people that can do that and are publicly known address for doing
> this is a good thing to me. If we lose the punitive focus and have more
> "what we want to do and what should happen" and less "what should not
> happen and how badly we'll punish you", it would be much better.


agree, and this was also mentioned previously my others, so I can't add
much to it.

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

Re: [PHP-DEV] [RFC] Normalize token_get_all() output (with flag)

[Sara Golemon]

On Tue, Jan 5, 2016 at 6:16 AM, Nikita Popov  wrote:
> Would be nice if someone could come up with a more explicit name for the
> flag. TOKEN_FULL is not obvious, at least to me. TOKEN_ALWAYS_ARRAY?
>
Yeah, I'm not a huge fan of the name either, but I couldn't come up
with anything better at the time.

Maybe TOKEN_ASSOC? Since it provides associative array elements (as
opposed to the current indexed array behavior)

> I'd also like to have a flag TOKEN_NO_LINENOS with deduplication of token
> arrays, but that's a separate matter...
>
Not sure what you're suggesting here.  Can you elaborate?

-Sara

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

Re: [PHP-DEV] Deprecation of the Error Control Operator (@ symbol)

[Rowan Collins]

Ferenc Kovacs wrote on 05/01/2016 18:09:

sure and most projects check the error_reporting() level against the $errno
like in the manual:
 if (!(error_reporting() & $errno)) {
 // This error code is not included in error_reporting
 return;
 }

@ changes the error_reporting() level for that particular call, so those
custom error handler won't throw exceptions for the suppressed errors but
when you remove/nop @ their code would throwing stuff left and right.


I'm lost - how does this validate the claim that building scream mode 
into core would lead to problems? We already have an ini setting which 
can change the error_reporting level, so any error handler relying on 
that is *already* subject to different behaviour in different 
environments. Any codebase which wants to ignore the settings of the 
environment would surely already omit that boilerplate, and thus be 
unaffected by the presence or functionality of the @ operator.


Regards,
--
Rowan Collins
[IMSoP]

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

[PHP-DEV] Re: Proposed change in json_encode+JSON_UNESCAPED_UNICODE behavior

[Andrea Faulds]

Hi Eddie,

Eddie Kohler wrote:

The U+2028 LINE SEPARATOR and U+2029 PARAGRAPH SEPARATOR
characters are allowed unescaped in JSON strings, but *not* allowed unescaped
in Javascript. This is widely considered a minor wart in the JSON specification.


As a result, the JSON_UNESCAPED_UNICODE flag is dangerous to use when
generating HTML. For example, this will generate a Javascript error ("Unexpected
token ILLEGAL") in the user's browser:

```
$x = mb_convert_encoding('', 'UTF-8', 'HTML-ENTITIES');
echo 'x = ', json_encode($x, JSON_UNESCAPED_UNICODE), ';';
```

The proposal is for `json_encode(..., JSON_UNESCAPED_UNICODE)` to
escape the U+2028 and U+2029 characters as \u2028 and \u2029. A new flag,
JSON_UNESCAPED_LINE_TERMINATORS, preserves the former behavior.

It's important to note that this change *only* affects the non-default
JSON_UNESCAPED_UNICODE flag.


This sounds reasonable. I'd like to ask, though, does this mean that 
without that flag, U+2028 and U+2029 are always escaped?


Thanks.
--
Andrea Faulds
https://ajf.me/

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

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[Anthony Ferrara]

Larry

>> I'll chime in on this, since you and I had a quite pleasant and
>> productive conversation last night.  I believe we agreed that the
>> original draft was over-focused on punitive measures and not enough on
>> low-impact mediation.
>>
>> I imagine, because I love all you guys (and gals), that the volume of
>> traffic to a response team would be low to begin with.  I further
>> imagine, since you're all such a great bunch of lads (and lasses),
>> that the vast majority of those complaints would be resolvable with
>> some gentle mediation.  That's a good focus for the CoC, and I would
>> love to bring us to that point.  (Sorry if you've already addressed
>> this Anthony, I haven't read your updates yet, it's been a busy
>> morning).
>>
>> I said it in a prior email, but I'll repeat it.  I see it like the
>> security@ list.  A place to send issues that don't necessarily bear
>> airing in public.  That's good for both the accuser AND the accused.
>> A tiny layer of discretion to ease what may be a tense issue.
>>
>> I don't, however, agree that the response team should be entirely
>> toothless.  As a *last resort*, a (no more than) 7 day ban to act as a
>> cooling off period isn't "vast sweeping powers", it's a band-aid for a
>> situation that's gotten out of control.  A situation that demands the
>> wider community's attention, because it's become unacceptable.  We can
>> define the limits of these powers (again I've said this in a previous
>> email).
>>
>> Worried about abuse of temp-bans?  Don't think a stringent requirement
>> of justification is enough?  How about the accuser must suffer an
>> equal ban?  By the time it's come to the point where action must be
>> taken, the problem has escalated to the point where privacy of the
>> accused won't be maintainable anyway (due to evidence requirements).
>> Turn the temp-ban into a cooling off period.  Because honestly, do we
>> have mustache twirling ne'er-do-wells? Or do we have passionate people
>> who get worked up into a lather and sometimes cross a line?
>>
>> As someone who has crossed that line more than once, I hope you'll
>> trust it's just the latter.
>>
>> -Sara
>
>
> I agree with Stas (previous email) that a bad CoC can backfire.  I'd go as
> far as saying that a bad CoC (either one that is so toothless as to be a lie
> or one that is so draconian that everyone lives in fear of it) is worse than
> no CoC at all.  That is, I think, the point of this discussion: Make sure
> that a CoC is adopted that is good and has a positive impact, not bad with a
> negative impact.
>
> Which is where I agree with Sara: A good CoC should be positive and focused
> on conflict-resolution, not on punitive measures.  So let's build a good
> conflict-resolution-oriented CoC and process rather than a
> ban-hammer-mechanism.  Also, recall that this is not a for-all-time
> definition.  CoCs can and should evolve over time, as should the process
> around them.
>
> Disclosure: I've been through Drupal's Community CoC, the DrupalCon CoC, and
> multiple rounds of CoC-esque discussion in a 20-year old online RPG club I
> used to help run.  I've been around this block more than once.
>
> Reference material:
>
> Drupal's Community CoC:
>
> https://www.drupal.org/dcoc
>
> was derived originally from the Ubuntu Community CoC:
>
> http://www.ubuntu.com/about/about-ubuntu/conduct
>
> The DrupalCon CoC was more contentious until it was rewritten to be more
> positive-oriented (less "we don't" and more "we do"):
>
> https://austin2014.drupal.org/code-of-conduct.html
>
> The main author of the DrupalCon CoC, George DeMet, pointed me at the Django
> CoC as another good model:
>
> https://www.djangoproject.com/conduct/
>
> Sara, Stas, Anthony, are you open to talking with George? (Disclosure:
> Besides being on the Drupal CWG, George is also my boss. )


Definitely! I overall like Drupals CoC (I looked at it in response to
this thread). Thanks for offering to set something up!

Anthony

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

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[Larry Garfield]

On 1/5/16 1:03 PM, Sara Golemon wrote:

On Tue, Jan 5, 2016 at 10:27 AM, Kevin Smith  wrote:

Much of the argument in favor of a code of conduct seems to be centered around 
the desire to send a message to the wider developer world that we’re a 
welcoming community that doesn’t look kindly on poor treatment of others. If 
that’s the goal, rather than the goal being to punish or censor people who 
violate our own values, why do we need a response team with the power to ban?

If a person's treatment of others truly warrants banishment, then as Zeev noted 
the RFC process is already perfectly suited for that. As far as I’m concerned, 
the absolute greatest power the response team should be given is the power to 
issue a censure. If sending a message is the goal, that’ll do it.



I'll chime in on this, since you and I had a quite pleasant and
productive conversation last night.  I believe we agreed that the
original draft was over-focused on punitive measures and not enough on
low-impact mediation.

I imagine, because I love all you guys (and gals), that the volume of
traffic to a response team would be low to begin with.  I further
imagine, since you're all such a great bunch of lads (and lasses),
that the vast majority of those complaints would be resolvable with
some gentle mediation.  That's a good focus for the CoC, and I would
love to bring us to that point.  (Sorry if you've already addressed
this Anthony, I haven't read your updates yet, it's been a busy
morning).

I said it in a prior email, but I'll repeat it.  I see it like the
security@ list.  A place to send issues that don't necessarily bear
airing in public.  That's good for both the accuser AND the accused.
A tiny layer of discretion to ease what may be a tense issue.

I don't, however, agree that the response team should be entirely
toothless.  As a *last resort*, a (no more than) 7 day ban to act as a
cooling off period isn't "vast sweeping powers", it's a band-aid for a
situation that's gotten out of control.  A situation that demands the
wider community's attention, because it's become unacceptable.  We can
define the limits of these powers (again I've said this in a previous
email).

Worried about abuse of temp-bans?  Don't think a stringent requirement
of justification is enough?  How about the accuser must suffer an
equal ban?  By the time it's come to the point where action must be
taken, the problem has escalated to the point where privacy of the
accused won't be maintainable anyway (due to evidence requirements).
Turn the temp-ban into a cooling off period.  Because honestly, do we
have mustache twirling ne'er-do-wells? Or do we have passionate people
who get worked up into a lather and sometimes cross a line?

As someone who has crossed that line more than once, I hope you'll
trust it's just the latter.

-Sara


I agree with Stas (previous email) that a bad CoC can backfire.  I'd go 
as far as saying that a bad CoC (either one that is so toothless as to 
be a lie or one that is so draconian that everyone lives in fear of it) 
is worse than no CoC at all.  That is, I think, the point of this 
discussion: Make sure that a CoC is adopted that is good and has a 
positive impact, not bad with a negative impact.


Which is where I agree with Sara: A good CoC should be positive and 
focused on conflict-resolution, not on punitive measures.  So let's 
build a good conflict-resolution-oriented CoC and process rather than a 
ban-hammer-mechanism.  Also, recall that this is not a for-all-time 
definition.  CoCs can and should evolve over time, as should the process 
around them.


Disclosure: I've been through Drupal's Community CoC, the DrupalCon CoC, 
and multiple rounds of CoC-esque discussion in a 20-year old online RPG 
club I used to help run.  I've been around this block more than once.


Reference material:

Drupal's Community CoC:

https://www.drupal.org/dcoc

was derived originally from the Ubuntu Community CoC:

http://www.ubuntu.com/about/about-ubuntu/conduct

The DrupalCon CoC was more contentious until it was rewritten to be more 
positive-oriented (less "we don't" and more "we do"):


https://austin2014.drupal.org/code-of-conduct.html

The main author of the DrupalCon CoC, George DeMet, pointed me at the 
Django CoC as another good model:


https://www.djangoproject.com/conduct/

Sara, Stas, Anthony, are you open to talking with George? (Disclosure: 
Besides being on the Drupal CWG, George is also my boss. )


--
--Larry Garfield


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

Re: [PHP-DEV] Re: [RFC] [Draft] Adopt Code of Conduct

[Anthony Ferrara]

Zeev,

On Tue, Jan 5, 2016 at 3:10 PM, Zeev Suraski  wrote:
>> -Original Message-
>> From: Anthony Ferrara [mailto:ircmax...@gmail.com]
>> Sent: Tuesday, January 05, 2016 6:16 PM
>> To: internals@lists.php.net
>> Subject: [PHP-DEV] Re: [RFC] [Draft] Adopt Code of Conduct
>>
>> As to the comments in this thread, I won't reply to every one, but here
>> are a
>> few points I'd like to make.
>
> Anthony,
>
> Thanks - I think the new draft looks much better and addresses much of my
> feedback.  I still think it puts too much emphasis on the mechanics and
> punitive actions, see below.

Awesome. It very well may be too hard on the punitive actions. A
balance is surely the correct approach, I was more talking against
lack of any "recourse". But am very much open to tweaking the level
and tone.

>>
>> It's been mentioned that we may want to adopt a CoC, but it shouldn't
>> "have teeth". I disagree here, as without an enforcement mechanism it
>> basically is no different from where we are at today.
>
> I think it's actually very different.  Today we have no CoC.  Stating a
> direction, a vision for the community - can go a very long way.  To
> illustrate, I suspect most of us are law-abiding citizens not because we're
> afraid of being thrown to jail - but rather, because we value the rule of
> law and know that abiding the law is the Right Thing to do.  If we simply
> adopt a CoC without adding teeth to it, we'd certainly not be the first
> project to do so.

True, but as Larry said, either side is problematic. Too loose of a
CoC with no enforcement and nothing really was changed from today
considering we already have the post that Rasmus made 6-7 years ago.
Sure, it's something to rally behind, but it doesn't really solve any
problems. The problem is that there's no safe way for people to get
help. The CoC is part of the solution to that, but not the only one.

>> Saying we should act
>> reasonable is fine, but we need a method for what we are to do when one of
>> us acts unreasonably.  Additionally, as has been stated, requiring people
>> to
>> report publicly creates a barrier to entry. Many people will simply chose
>> to
>> leave quietly rather than report publicly.
>> Simply look at the way people who speak out about harassment are treated
>> in public to understand why. The point of the CoC is to create a safe
>> place
>> for everyone to contribute, not just those with thick skin.
>
> My main concern is/was that we're venturing into areas where we have
> absolutely no experience and completely inadequate training.  We are not
> legislators nor lawyers;  We've demonstrated more than once that we're not
> very good at establishing 'written law' for far simpler and non-ambiguous
> things, failing to predict all possible scenarios of the future.  The fact
> we need to borrow definitions from Criminal Law should be an indicator that
> we're probably venturing in the wrong direction here.  The system
> responsible for implementing the law, as we all know, is complex and with
> countless checks and balances - and as I think we all know, it is also
> subjective, completely open for interpretation and with a very strong human
> element - and consequently frequently fails.  My concern is that we're
> trying to sketch a simplistic system which would fail us in unpredictable
> ways in the future, when the rubber meets the road.
>
> And with all that said, it seems to be much less of an issue with the
> updated RFC, given the reduced power of the CoC team and the changed
> 'spirit' of it.  I do need to review the RFC more closely though.

Yeah, I never intended it to be a "law document". The main reason for
the CoC Team was to respect confidentiality and not require full
public disclosure of all incidents (which will drive people away). The
exact tone and language definitely still needs work.

The main reason for posting it soon was to start the conversation, not
finish it. In fact, I can see a very real world where the majority of
the policies around the CoC team are replaced with
https://www.drupal.org/conflict-resolution or something similar. The
presence of the team is the important part to me, not the strength or
precise process.

>> As to why the Contributor Covenant as opposed to another CoC or our own
>> custom one, there are two reasons for this. First, it's a standard that's
>> been
>> adopted by a number of significant scale projects. Second, it saves us
>> from
>> having to bikeshed over every single word of a CoC.
>> If there's another standard CoC that we should entertain, I'm happy to
>> look
>> at it. But I do not believe that we should create our own.
>
> I think the Contributor Covenant is problematic when used as a law, as
> opposed to guidelines - because it's way too open ended.
> But again - with the substantial changes to the RFC, I think it's less of an
> issue.
>
> Thanks again for the efforts on this!

Yeah, I'm not locked to the Contributor Covenant. If there's another

Re: [PHP-DEV] RFC: Deprecate mb_ereg_replace eval option

[Rouven Weßling]

Hi Dan,

> On 04 Jan 2016, at 20:52, Dan Ackroyd  wrote:
> 
> Are the wrong functions are listed in this sentence: "Emit an
> E_DEPRECATED error whenever mb_ereg_replace_callback or
> mb_eregi_replace_callback is called with the e option." As the RFC is
> meant to be about mb_ereg_replace, mb_eregi_replace right?

Indeed. Thanks for spotting it.

> The RFC doesn't say what functions people should use in place of the
> deprecated functions. This needs to be laid out clearly. I can guess
> what should happen for mb_ereg_replace, but there's not clear
> replacement for mb_eregi_replace, as there is no
> "mb_eregi_replace_callback" function. That ought to be thought about
> and added to the RFC.

That information is the section "Backward Incompatible Changes”, which 
admittedly may not be the most obvious place to look. To quote that section:

“The suggested replacement, mb_ereg_replace_callback is has only been available 
since PHP 5.4.1. Projects which support both PHP 5.3 and PHP 7.1 may need two 
code paths to avoid deprecation warnings.

There is no mb_eregi_replace_callback function. Code using it will have to be 
converted to use mb_ereg_replace_callbackwith the i option."

>> The mandatory discussion period will end January 19th.
> 
> That sentence is implying that you will put it to the vote as soon as
> possible. Please don't do that.  There is no rush to deprecate these
> functions; the earliest they would actually be removed is years away,
> and there needs to be a path guiding the people on how to replace that
> functionality in place before we deprecate them.

The implication wasn’t my attention. It was mostly a reminder for myself how 
long I have to keep the discussion open. That said, I hope this isn’t 
controversial due to the similar RFC about pre_replace passing 4 years ago.

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

RE: [PHP-DEV] Deprecation of the Error Control Operator (@ symbol)

[Zeev Suraski]

> -Original Message-
> From: Rasmus Lerdorf [mailto:ras...@lerdorf.com]
> Sent: Tuesday, January 05, 2016 7:28 AM
> To: Sara Golemon; Stanislav Malyshev
> Cc: Junade Ali; PHP internals
> Subject: Re: [PHP-DEV] Deprecation of the Error Control Operator (@
> symbol)
>
> On 01/04/2016 07:22 PM, Sara Golemon wrote:
> > On Thu, Dec 31, 2015 at 1:10 PM, Stanislav Malyshev
>  wrote:
> >> I don't think it is a good idea, currently, for the following reasons:
> >>
> > [::snip::]
> >
> > It terrifies me to say this, but I completely agree with Stas. ;)
> >
> > I can't personally remember the last time I used @ in any production
> > code, but my one-offs are replete with them.  It's a quintessentially
> > PHP feature in its pragmatism.
> >
> > Okay, I'll put the thesaurus down.
>
> I'd be quite sad to see @ disappear as well. It was one of PHP's earliest
> features and its roots date back to mid-80's DOS batch files (before 1/3
> of
> this list were born I would guess)

Same here.

Zeev

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

Re: [PHP-DEV] Deprecation of the Error Control Operator (@ symbol)

[Derick Rethans]

On Tue, 5 Jan 2016, Michael Heap wrote:

> 
> On Tue, Jan 5, 2016 at 5:45 AM, Sara Golemon  wrote:
> 
> > On Thu, Dec 31, 2015 at 6:52 AM, Junade Ali  wrote:
> > > I am looking to submit an RFC in order to remove the error suppression
> > > operator in PHP, namely the @ symbol.
> > >
> > Forwarding a suggestion twitter/@Beryllium9:
> >
> > How about a global "disable error suppression" setting?  That way a 
> > project lead could enforce it for their codebase (and guarantee that 
> > devs "aren't lazy"), but PHP doesn't lose its pragmatism?

> Sounds like the xdebug.scream or the Scream PECL extension ( 
> https://pecl.php.net/package/scream) to me.
> 
> +1 for baking this functionality into core

That's going to mean an INI setting.. that hosters could abuse. Having 
an INI setting like this as part of core is IMO not a great idea.

cheers,
Derick

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

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

RE: [PHP-DEV] Deprecation of the Error Control Operator (@ symbol)

[Zeev Suraski]

> -Original Message-
> From: Derick Rethans [mailto:der...@php.net]
> Sent: Tuesday, January 05, 2016 12:57 PM
> To: Michael Heap
> Cc: Sara Golemon; Junade Ali; PHP internals
> Subject: Re: [PHP-DEV] Deprecation of the Error Control Operator (@
> symbol)
>
> On Tue, 5 Jan 2016, Michael Heap wrote:
>
> >
> > On Tue, Jan 5, 2016 at 5:45 AM, Sara Golemon  wrote:
> >
> > > On Thu, Dec 31, 2015 at 6:52 AM, Junade Ali  wrote:
> > > > I am looking to submit an RFC in order to remove the error
> > > > suppression operator in PHP, namely the @ symbol.
> > > >
> > > Forwarding a suggestion twitter/@Beryllium9:
> > >
> > > How about a global "disable error suppression" setting?  That way a
> > > project lead could enforce it for their codebase (and guarantee that
> > > devs "aren't lazy"), but PHP doesn't lose its pragmatism?
>
> > Sounds like the xdebug.scream or the Scream PECL extension (
> > https://pecl.php.net/package/scream) to me.
> >
> > +1 for baking this functionality into core
>
> That's going to mean an INI setting.. that hosters could abuse. Having
an INI
> setting like this as part of core is IMO not a great idea.

I agree.  Perhaps through a declare() statement instead?  We could easily
make it file-based, so that the declare() statement only affects the local
file, or we could make it global for the entire request.

Zeev

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

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[Peter Petermann]

I don't think this is a good idea.

the proposed code of conduct (contributor covenant) is extremly open to
interpretation, as it is very subjective where harassment starts, what
personal attacks are, if something is trolling, and i don't even want to
see a discussion if something someone said is sexualized or not.

We are in an environment here, in which people from various cultural
backgrounds and mother tongues. What is understood is not always what was
said (or meant)

And frankly, I can recall more than one occasion where there have been
things that I'd consider personal attacks, including declaring that i
shouldn't be allowed to vote by Anthony, where till today i haven't seen an
apology for.

No seriously, this (to me) seems an attempt to create an instrument that
can be used to discredit and silence others.

I just have to look back on the whole dual-mode vote, where a hand full of
us old-guys stood in conflict with a lot of the newer guys, including
Anthonys "voting irregularities" mail, and i can see how a vote on who
would be in the "response team" would swing, and how the vague code of
conduct would be used afterwards.

best regards,
Peter Petermann

On Mon, Jan 4, 2016 at 10:07 PM Anthony Ferrara  wrote:

> Hey all,
>
> I have created a new RFC for the PHP Project to adopt the Contributor
> Covenant as the official Code of Conduct for the project
>
> https://wiki.php.net/rfc/adopt-code-of-conduct
>
> Let me know what you think or if there are any concerns
>
> Thanks
>
> Anthony
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
> --
Peter Petermann
ProtonMail: ppeterm...@protonmail.com (encrypted / based in .ch)
Email: ppeterman...@gmail.com - get my public PGP key from SKS Keyservers
PGP Key:
http://pool.sks-keyservers.net:11371/pks/lookup?op=get=0x0E6DBD675836A5C7

Re: [PHP-DEV] Re: [RFC] [Draft] Adopt Code of Conduct

[Sara Golemon]

On Tue, Jan 5, 2016 at 12:21 PM, Anthony Ferrara  wrote:
>>> It's been mentioned that we may want to adopt a CoC, but it shouldn't
>>> "have teeth". I disagree here, as without an enforcement mechanism it
>>> basically is no different from where we are at today.
>>
>> I think it's actually very different.  Today we have no CoC.  Stating a
>> direction, a vision for the community - can go a very long way.  To
>> illustrate, I suspect most of us are law-abiding citizens not because we're
>> afraid of being thrown to jail - but rather, because we value the rule of
>> law and know that abiding the law is the Right Thing to do.  If we simply
>> adopt a CoC without adding teeth to it, we'd certainly not be the first
>> project to do so.
>
> True, but as Larry said, either side is problematic. Too loose of a
> CoC with no enforcement and nothing really was changed from today
> considering we already have the post that Rasmus made 6-7 years ago.
> Sure, it's something to rally behind, but it doesn't really solve any
> problems. The problem is that there's no safe way for people to get
> help. The CoC is part of the solution to that, but not the only one.
>
Perhaps there's a path to compromise here though.  A CoC plus a
Response Team *without* authority for any punitive action would be a
step forward.  We don't have to solve every problem right up front, we
can start with:

1) Provide a channel for safe reporting of incidents (and again, I
speak of the safety of both accuser and accused).
2) Open safe dialogues between parties without airing drama and dirty
laundry on the list.
3) Track statistics.  We have no data on who's leaving quietly due to
conflict.  This can help us gather some of that. (And yes, I'm vague
on how we can collate those stats, because I don't know yet - It's
still a draft)

Will the lack of teeth have less of a deterrence effect?  Probably,
but to paraphrase some sentiments, this isn't a war-zone.  And
punitive powers do exist in the hands of people have earned the right
to have those powers. I for one, am willing to sacrifice the band-aid
of a temp-ban on the altar of compromise.

Having a clear statement of expected conduct is a good thing, be it as
vague as "Be nice" or as specific as "Don't lower yourself to name
calling and all caps shouting."  Having a response team who's job it
is to help mediate when things go wrong is a good thing.  We can leave
the pistols at home.

There's still 360 days left in the year for followup RFCs if this
doesn't work out, and years left in the project.

-Sara

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

Re: [PHP-DEV] Deprecation of the Error Control Operator (@ symbol)

[Derick Rethans]

On Tue, 5 Jan 2016, Sara Golemon wrote:

> On Tue, Jan 5, 2016 at 3:57 AM, Zeev Suraski  wrote:
>
> >> From: Derick Rethans [mailto:der...@php.net]
> >> That's going to mean an INI setting.. that hosters could abuse.
> >> Having an INI setting like this as part of core is IMO not a great idea.
> >
> I honestly don't understand why that's a bad idea.  There are a LOT of 
> settings that hosters could abuse, but as a general rule they don't, 
> because it breaks client apps and clients leave.
> 
> A hoster could just as easily install XDebug and turn that setting on. 
> Are they doing that?
> 
> Or are you, Derick Rethans, suggesting that installing XDebug is a bad idea? 
> ;)

On a production environment, certainly not a good idea.

cheers,
Derick

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

Re: [PHP-DEV] Re: [RFC] [Draft] Adopt Code of Conduct

[Chase Peeler]

While overall I tend to agree with Paul on the concept of a CoC, I don't
think that precludes the ability to offer suggestions. It's to everyone's
advantage to make sure that if we do adopt a CoC, we adopt the best one
possible.

Obviously one of the biggest fears is unjust treatment of the accused. The
thing that is most likely to lead to that would be pre-existing personal
biases towards the accused (or in favor of the accuser) by a member of the
committee. Why not require that at least one member come from outside the
PHP community all together. I don't know how feasible that really is, but
assuming it is, it's probably the best way to ensure that there is at least
one person that is more likely to be as unbiased as possible.

That member could be voted on like all the other members, or, due to the
fact that voters are hopefully less familiar with such candidates, be
appointed by the elected members of the committee.

Obviously it's not perfect and still allows the possibility of abuse, but
you reach the point where such abuses almost require a coordinated
conspiracy.


On Tue, Jan 5, 2016 at 4:15 PM Sara Golemon  wrote:

> On Tue, Jan 5, 2016 at 12:21 PM, Anthony Ferrara 
> wrote:
> >>> It's been mentioned that we may want to adopt a CoC, but it shouldn't
> >>> "have teeth". I disagree here, as without an enforcement mechanism it
> >>> basically is no different from where we are at today.
> >>
> >> I think it's actually very different.  Today we have no CoC.  Stating a
> >> direction, a vision for the community - can go a very long way.  To
> >> illustrate, I suspect most of us are law-abiding citizens not because
> we're
> >> afraid of being thrown to jail - but rather, because we value the rule
> of
> >> law and know that abiding the law is the Right Thing to do.  If we
> simply
> >> adopt a CoC without adding teeth to it, we'd certainly not be the first
> >> project to do so.
> >
> > True, but as Larry said, either side is problematic. Too loose of a
> > CoC with no enforcement and nothing really was changed from today
> > considering we already have the post that Rasmus made 6-7 years ago.
> > Sure, it's something to rally behind, but it doesn't really solve any
> > problems. The problem is that there's no safe way for people to get
> > help. The CoC is part of the solution to that, but not the only one.
> >
> Perhaps there's a path to compromise here though.  A CoC plus a
> Response Team *without* authority for any punitive action would be a
> step forward.  We don't have to solve every problem right up front, we
> can start with:
>
> 1) Provide a channel for safe reporting of incidents (and again, I
> speak of the safety of both accuser and accused).
> 2) Open safe dialogues between parties without airing drama and dirty
> laundry on the list.
> 3) Track statistics.  We have no data on who's leaving quietly due to
> conflict.  This can help us gather some of that. (And yes, I'm vague
> on how we can collate those stats, because I don't know yet - It's
> still a draft)
>
> Will the lack of teeth have less of a deterrence effect?  Probably,
> but to paraphrase some sentiments, this isn't a war-zone.  And
> punitive powers do exist in the hands of people have earned the right
> to have those powers. I for one, am willing to sacrifice the band-aid
> of a temp-ban on the altar of compromise.
>
> Having a clear statement of expected conduct is a good thing, be it as
> vague as "Be nice" or as specific as "Don't lower yourself to name
> calling and all caps shouting."  Having a response team who's job it
> is to help mediate when things go wrong is a good thing.  We can leave
> the pistols at home.
>
> There's still 360 days left in the year for followup RFCs if this
> doesn't work out, and years left in the project.
>
> -Sara
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
> --
-- Chase
chasepee...@gmail.com

Re: [PHP-DEV] Re: [RFC] Normalize token_get_all() output (with flag)

[Sara Golemon]

On Tue, Jan 5, 2016 at 12:52 PM, Andrea Faulds  wrote:
> This is more of a side-note, but maybe it's worth bringing up. Since
> token_get_all gives an array with subarrays of a regular structure, might it
> be worthwhile returning an array of objects instead? It would probably
> reduce memory usage (assuming they're objects of a Token class or something,
> not StdClass), but I don't know if it's that useful.
>
Is the internal memory usage of (new stdClass) actually less than
(array())?  I know array changed a lot with PHP7, and that the kind of
array we're talking about here is a mixed (which would be the least
efficient), but I don't have the numbers to hand.

To your question, I'm cool either way.  Though if memory/efficiency is
a concern, returning an iterator would be even better, especially on
large files.  Though I think that's beyond the scope of this
particular RFC.

Maybe I should keep up my "1 RFC per day" run and suggest
TOKEN_ITERATOR as yet another flag   Maybe not.  My inbox hurts.

-Sara

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

Re: [PHP-DEV] Re: [RFC] [Draft] Adopt Code of Conduct

[Anthony Ferrara]

Chase,

On Tue, Jan 5, 2016 at 4:51 PM, Chase Peeler  wrote:
> While overall I tend to agree with Paul on the concept of a CoC, I don't
> think that precludes the ability to offer suggestions. It's to everyone's
> advantage to make sure that if we do adopt a CoC, we adopt the best one
> possible.
>
> Obviously one of the biggest fears is unjust treatment of the accused. The
> thing that is most likely to lead to that would be pre-existing personal
> biases towards the accused (or in favor of the accuser) by a member of the
> committee. Why not require that at least one member come from outside the
> PHP community all together. I don't know how feasible that really is, but
> assuming it is, it's probably the best way to ensure that there is at least
> one person that is more likely to be as unbiased as possible.
>
> That member could be voted on like all the other members, or, due to the
> fact that voters are hopefully less familiar with such candidates, be
> appointed by the elected members of the committee.
>
> Obviously it's not perfect and still allows the possibility of abuse, but
> you reach the point where such abuses almost require a coordinated
> conspiracy.

Thanks for the suggestion!

So that would mean there would be 3 "required seats":

 * PHP-SRC karma
 * PHP-DOCs karma
 * no karma

and then 2 "arbitrary" seats.

I like the idea overall, but would very much like to hear other's
feedback prior to adding that.

Thanks!

Anthony

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

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[Paul M. Jones]

> On Jan 5, 2016, at 18:19, Pierre Joye  wrote:
> 
> On Jan 6, 2016 1:03 AM, "Ferenc Kovacs"  wrote:
> 
>>> Who would like to be connected with the Drupal people in this space, if
> I
>>> can get their time?  I figure Anthony and Stas are good to include there
>>> (proposer and someone with well-reasoned concerned). One or two more
> people?
>>> 
>>> --
>>> --Larry Garfield
>>> 
>>> 
>>> 
>>> --
>>> PHP Internals - PHP Runtime Development Mailing List
>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>> 
>>> 
>> Maybe Sarah and Paul and with that we covered every angle :)
> 
> Paul?

Sure, I'll bite.



-- 
Paul M. Jones
pmjone...@gmail.com
http://paul-m-jones.com

Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp

Solving the N+1 Problem in PHP
https://leanpub.com/sn1php



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

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[Pierre Joye]

On Jan 6, 2016 7:53 AM, "Paul M. Jones"  wrote:
>
>
> > On Jan 5, 2016, at 18:19, Pierre Joye  wrote:
> >
> > On Jan 6, 2016 1:03 AM, "Ferenc Kovacs"  wrote:
> >
> >>> Who would like to be connected with the Drupal people in this space,
if
> > I
> >>> can get their time?  I figure Anthony and Stas are good to include
there
> >>> (proposer and someone with well-reasoned concerned). One or two more
> > people?
> >>>
> >>> --
> >>> --Larry Garfield
> >>>
> >>>
> >>>
> >>> --
> >>> PHP Internals - PHP Runtime Development Mailing List
> >>> To unsubscribe, visit: http://www.php.net/unsub.php
> >>>
> >>>
> >> Maybe Sarah and Paul and with that we covered every angle :)
> >
> > Paul?
>
> Sure, I'll bite.

I was asking which Paul. But no doubt you will ;)

Also why not as long as you are a tiny bit more constructive.

Cheers
Pierre

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[Terry Cullen]

Hi,

On 6 January 2016 at 09:20, Paul M. Jones  wrote:

>
> > On Jan 5, 2016, at 17:09, Terry Cullen  wrote:
> >
> > Hi,
> >
> >
> >
> > On 5 January 2016 at 07:06, Anthony Ferrara  wrote:
> >
> >> Hey all,
> >>
> >> I have created a new RFC for the PHP Project to adopt the Contributor
> >> Covenant as the official Code of Conduct for the project
> >>
> >> https://wiki.php.net/rfc/adopt-code-of-conduct
> >>
> >> Let me know what you think or if there are any concerns
> >>
> >> Thanks
> >>
> >> Anthony
> >>
> >> --
> >> PHP Internals - PHP Runtime Development Mailing List
> >> To unsubscribe, visit: http://www.php.net/unsub.php
> >>
> >>
> > ​Here is a timely blog post of a FreeBSD community member's account of
> > bullying within a large OS project.  I thought it might add to the
> > conversation...
> >
> >
> http://blog.randi.io/2015/12/31/the-developer-formerly-known-as-freebsdgirl/
>
> And here's a timely reference from the other side of that argument.
>
>
> https://lists.freebsd.org/pipermail/freebsd-questions/2015-June/266479.html
>
> If one presents only the one side, that of the accuser, that might be
> problematic.  It's even more problematic when speech is being policed by a
> COC.
>
>
>
​Yes... Enforcing a COC can be a ​very complicated undertaking.




>
> --
> Paul M. Jones
> pmjone...@gmail.com
> http://paul-m-jones.com
>
> Modernizing Legacy Applications in PHP
> https://leanpub.com/mlaphp
>
> Solving the N+1 Problem in PHP
> https://leanpub.com/sn1php
>
>
>
​Terry​

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[Pierre Joye]

On Jan 6, 2016 1:03 AM, "Ferenc Kovacs"  wrote:

> > Who would like to be connected with the Drupal people in this space, if
I
> > can get their time?  I figure Anthony and Stas are good to include there
> > (proposer and someone with well-reasoned concerned). One or two more
people?
> >
> > --
> > --Larry Garfield
> >
> >
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
> Maybe Sarah and Paul and with that we covered every angle :)

Paul?

Re: [PHP-DEV] token_get_all(): additional location information, and raw tokens

[Sara Golemon]

On Tue, Jan 5, 2016 at 3:57 PM, Fred Emmott  wrote:
>  - T_ELSEIF to T_ELSE T_WHITESPACE T_IF
>
HHVM only does that when the text of T_ELSEIF is "else\w+if" which
happens because of a fugly lexer hack which yeah... let's not talk
about that.

-Sara

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

Re: [PHP-DEV] Deprecation of the Error Control Operator (@ symbol)

[Sara Golemon]

On Tue, Jan 5, 2016 at 11:40 AM, Rowan Collins  wrote:
>> @ changes the error_reporting() level for that particular call, so those
>> custom error handler won't throw exceptions for the suppressed errors but
>> when you remove/nop @ their code would throwing stuff left and right.
>
>
> I'm lost - how does this validate the claim that building scream mode into
> core would lead to problems? We already have an ini setting which can change
> the error_reporting level, so any error handler relying on that is *already*
> subject to different behaviour in different environments. Any codebase which
> wants to ignore the settings of the environment would surely already omit
> that boilerplate, and thus be unaffected by the presence or functionality of
> the @ operator.
>
Because no matter how high your error_reporting is set (globally,
per-dir, or ini-set) the @ suppression operator temporarily resets it
to zero.  In psuedo-code the following two blocks are equivalent:

@foo();

if (ini_get('scream')) {
  $old_reporting = error_reporting(0);
}
foo();
if (ini_get('scream')) {
  error_reporting($old_reporting);
}

So the argument being made is that being able to disable @ suppression
means ignoring whatever value the developer/admin has set for
error_reporting.

-Sara (not taking a stand on whether that's a compelling argument,
just clarifying it)

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

Re: [PHP-DEV] Re: Proposed change in json_encode+JSON_UNESCAPED_UNICODE behavior

[Eddie Kohler]

Yes, without the JSON_UNESCAPED_UNICODE flag, all characters with
Unicode values >= 0x80 are escaped. That's the default behavior.


On Tue, Jan 5, 2016 at 2:45 PM, Andrea Faulds  wrote:
> Hi Eddie,
>
> Eddie Kohler wrote:
>>
>> The U+2028 LINE SEPARATOR and U+2029 PARAGRAPH SEPARATOR
>> characters are allowed unescaped in JSON strings, but *not* allowed
>> unescaped
>> in Javascript. This is widely considered a minor wart in the JSON
>> specification.
>> 
>>
>> As a result, the JSON_UNESCAPED_UNICODE flag is dangerous to use when
>> generating HTML. For example, this will generate a Javascript error
>> ("Unexpected
>> token ILLEGAL") in the user's browser:
>>
>> ```
>> $x = mb_convert_encoding('', 'UTF-8', 'HTML-ENTITIES');
>> echo 'x = ', json_encode($x, JSON_UNESCAPED_UNICODE),
>> ';';
>> ```
>>
>> The proposal is for `json_encode(..., JSON_UNESCAPED_UNICODE)` to
>> escape the U+2028 and U+2029 characters as \u2028 and \u2029. A new flag,
>> JSON_UNESCAPED_LINE_TERMINATORS, preserves the former behavior.
>>
>> It's important to note that this change *only* affects the non-default
>> JSON_UNESCAPED_UNICODE flag.
>
>
> This sounds reasonable. I'd like to ask, though, does this mean that without
> that flag, U+2028 and U+2029 are always escaped?
>
> Thanks.
> --
> Andrea Faulds
> https://ajf.me/
>
> --
> 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] Deprecation of the Error Control Operator (@ symbol)

[Sara Golemon]

On Tue, Jan 5, 2016 at 12:24 PM, Aaron Piotrowski  wrote:
> Before anything can be done with the @ operator, changes will need to
> be made to remove warnings for conditions that the code has no way of
> checking prior to calling these functions.
>
I'd include pragmatism in that calculus.   fopen() can technically be
safely called, but only by adding a lot of boilerplate that makes code
ugly.   An @ suppression is perfectly reasonable provided the return
value is sanity checked.

-Sara

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

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[Terry Cullen]

Hi,



On 5 January 2016 at 07:06, Anthony Ferrara  wrote:

> Hey all,
>
> I have created a new RFC for the PHP Project to adopt the Contributor
> Covenant as the official Code of Conduct for the project
>
> https://wiki.php.net/rfc/adopt-code-of-conduct
>
> Let me know what you think or if there are any concerns
>
> Thanks
>
> Anthony
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
​Here is a timely blog post of a FreeBSD community member's account of
bullying within a large OS project.  I thought it might add to the
conversation...

http://blog.randi.io/2015/12/31/the-developer-formerly-known-as-freebsdgirl/

Terry Cullen

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[Paul M. Jones]

> On Jan 4, 2016, at 22:29, Paul M. Jones  wrote:
> 
> 
>> On Jan 4, 2016, at 21:48, Michael Cullum  wrote:
>> 
>> I do apologise for saying offender, it was the wrong word to use there

For the record: accepted.  The COC is a speech-policing code, so if it passes, 
expect even greater attention to mistakes and mis-speakings, and even greater 
consequences than embarrassment for "offenders" who are part of the out-group.


-- 
Paul M. Jones
pmjone...@gmail.com
http://paul-m-jones.com

Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp

Solving the N+1 Problem in PHP
https://leanpub.com/sn1php



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

Re: [PHP-DEV] Re: [RFC] [Draft] Adopt Code of Conduct

[Stanislav Malyshev]

Hi!

> Exhibit A:
> https://github.com/CoralineAda/contributor_covenant/commit/0e927bc01614d6b0de021a314dbe95e7dfcc7bb9#diff-eacf331f0ffc35d4b482f1d15a887d3bL17
>
>  Exhibit B: https://archive.is/dgilk (the threatening language at the
> end is particularly chilling)
> 

I think this kind of clearly polarizing and politicizing language and
this kind of threats and abuse of process which is designed to protect
people from abuse to bully them into accepting specific point is
something we want to steer clear from.

Fortunately, our community seems to have a blessing of being able to
rationally discuss this topic without getting into such extremes, so it
is not true in our case that people that support CoC come from the place
of politics and not just want to improve the community.

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

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

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[Larry Garfield]

On 1/5/16 4:30 PM, Paul M. Jones wrote:

On Jan 5, 2016, at 16:21, Nate Abele  wrote:

Hi Rowan,

I don’t presume to speak for Paul, but I don’t think the point is that any 
particular person involved in this discussion is presumed to have a political 
intent, rather that CoCs themselves (the Contributor Covenant in particular), 
and the people typically agitating for them, come from a place of 
hyper-politicization.

Yes, that is an accurate summary of my position.


It is also an inaccurate summary of your statements on this list to 
date, as well as elsewhere, which have been accusatory, vitriolic, 
insulting, and hyperbolic.


Yes, there are hyper-politicized people who push CoCs and use "if you 
sneeze around me I'm mortally offended and will have you fired" type 
arguments.  I do not dispute the presence and existence of such people.  
I also do not dispute the presence and existence of CoCs, and 
enforcements thereof, that are "guilty until proven innocent, which 
you're not allowed to do".  That does not imply that all CoCs are 
inherently such documents or that all who support the concept of a CoC 
are hyper-politicized crusaders hell-bent on world baby-ification.


I also do not dispute that there is an awful lot of really terrible PHP 
code in the wild that is riddled with more security holes than swiss 
cheese, written by people who, in the interests of public safety, should 
probably not be allowed to use a computer.  Does it therefore follow 
that all PHP code is inherently insecure and PHP developers are all 
intrinsically incompetent?  Of course not. Not even remotely.  Most of 
us on this list, you included Paul, have been in a position to point 
that out, probably repeatedly.


I dislike and would just as soon stamp out the "guilty until proven 
innocent" model of political correctness as much as you.  But that 
doesn't mean the world is all rainbows and ponies if we just didn't have 
CoCs.  There are real and legitimate issues in the IT world that need to 
be addressed, and a good CoC, fairly-enforced, is one useful tool in 
doing so.


In fact, I would go as far as saying that if you want to stomp out the 
"guilty until proven innocent" CoC movement, then a major project (like 
PHP) adopting a CoC that *does* strike a softer tone, focuses on 
conflict resolution, has teeth but rarely needs them, and otherwise 
shows that *a CoC needn't be a tool of social control* is the best 
argument that can be made.  Taking a balanced approach and showing that 
it can work is the best way to undermine and de-fang the extremists.  
(Both the "CoC as political weapon" crowd and the "I want the right to 
piss in your cheerios" crowd.)


Modeling the behavior of an extremist, however, is the best way to 
reinforce and embolden the counter-extremist.


--
--Larry Garfield


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