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

[Anthony Ferrara]

David,

On Mon, Jan 11, 2016 at 5:05 PM, David Zuelke  wrote:
> On 11.01.2016, at 12:31, Anthony Ferrara  wrote:
>
>> Actually, asking for proof and denying are the same thing. If they
>> weren't, then why would you be asking for proof unless you believed it
>> didn't happen?
>
> They are not the same thing. If you make a claim, then the onus of proof is 
> on you, and you cannot simply turn that reasonable request against them by 
> then implying they're denying. Otherwise, why have proof for anything at all?

Because the claim is tangential to the discussion. We're not talking
about passing an RFC which enumerates which incidents have happened.
The fact that incidents have happened doesn't change this RFC at all.
Some people denied that anything has happened in the first place, and
as a response to that, many (including myself) have stood up and said
"sorry, but things have happened". The burden of proof isn't on
anyone, because the entire line of discussion is off-topic.

And even if it was on-topic, the question wasn't (sic) "can you share
a concrete example so we can learn from it". The question was (sic) "I
haven't seen it happen" which is paramount to "prove it".

> To me, this begs the question: would you handle incidents covered by the CoC 
> in a similar way, with that same attitude? An accuser claims something, and 
> asking for proof will be interpreted as denial?
>
> By extension, will a third party asking for proof for an incident be subject 
> to kafkatrapping - "the fact that you're doubting X happened means you're 
> also guilty of X"? That one has happened to me before on twitter. Didn't 
> stick because of the ridiculousness, but maybe the conjured mob was simply 
> not large enough to spark sufficient outrage.

Which is precisely why asking for evidence and public discussion is
problematic. That's precisely what I was trying to avoid with having a
resolution team that had limited powers. To avoid the "public court"
as much as possible *precisely* because of the mob mentality *in both
directions*.

> I'm pretty uncomfortable that you as the person "in charge" of this RFC hold 
> such biased views. If you can't see that asking for proof and denial are 
> different things then that IMO disqualifies you for that role.

Ok. I'm disqualified then.

> The same applies to your claims of threats of violence. It's fine if you 
> don't want to provide details, but then you can't bring those cases up. It's 
> legitimate for others here to ask you for evidence if you do bring it up. I 
> understand that we're all different personalities and you're maybe more wired 
> in that direction (mentioning something in passing), but you need to 
> understand that once a claim is out there, it's up to you to back it up. If 
> you then refuse to, it raises doubts, and rightfully so.

I never said I don't want to provide details. I said I won't talk
about it publicly. I think that is a reasonable thing. Especially
since we're talking about creating a private channel for this sort of
discussion. To say I need to make it public or it doesn't count is
problematic. Especially since we're talking about a CoC here where
people may not feel comfortable talking publicly about incidents. And
several people have already stood up and said precisely that. So to
discount all of those incidents because people don't feel comfortable
(for whatever reason) talking publicly, isn't good.



Zeev,

> What clearly hasn't happened is any proponent of this RFC actually answering 
> these questions.

Because I (and others) believe that none of these questions are
actually related to the RFC. They are tangential and are distractions
from the prime point. The prime point is to actually figure out is
where we should move the proposal towards. Very few of the replies,
and none of the ones in the past 100 replies discuss this prime point.

IMHO answering these meta level questions, and having this meta level
discussion is a distraction from the entire point of the proposal.

> Is my email being ignored because I used the word 'judicial' to describe the 
> current RFC, and differentiate it from a regular CoC+mediation?
> Is it non constructive or hyperbole in your opinion?

No, I read your email. I haven't responded because I've been trying to
throttle my replies to this post, and had immediately responded to
another thread. Additionally, I don't believe that anything you
brought up hasn't already been discussed at some point in this 300+
reply thread.  But if nobody else covers the points I feel should be
made, I will reply tomorrow to it.

> Asking for proof is not at all the same as denying it exists.
> Not knowing that something exists, and even finding it difficult to believe 
> it does - is not the same as knowing that it doesn't exist / denying it.

When one person says something happens, asking for proof may be
reasonable and backup precisely what you say. However, that's not the
case here. At 

Re: [PHP-DEV] Re: Anonymous voting on wiki

[François Laupretre]

Hi Eli,

Le 11/01/2016 15:45, Eli a écrit :

On 1/10/16 8:15 AM, Dennis Birkholz wrote:

I would really like to understand the rational behind anonymous voting
in the PHP internals context. Votes for RFCs should be purely based on
technical reasons and whether the language change would benefit the
language in the long run or not. I see no reason why such a vote
should be confidential.


I will chime in my quick thoughts here Dennis, as to a reason I could
see for doing so ...  (Not going to argue if 'this reason is good
enough' or not.  But it is a valid reason)


If a person does not stand behind his/her opinion for a technical
change, I am not sure if that person should be allowed to decide the
future of the language.


So the reason is not because someone isn't willing to 'stand behind
their opinion'.  It's purely about being harassed (perhaps beleaguered
is a better terminology to not confuse this with 'illegal harassment')
for having said opinion.  I was one of the people who, due to my vote on
STH, immediately started being beleaguered for holding my views and for
voting as much.  My inbox/twitter/IRC/etc filled with how I was ruining
PHP and ruining people's lives.  Old friendships were threatened to be
ended.  And my entire week ended up becoming full of responding to these.

Instead of getting to be an informed voter, go in and cast my vote, and
await for the results to be displayed ... I become embroiled into the
arguments, back-n-forth, defense, and dealing with the beleaguering
comments.

Yes, I stood behind my opinion.   But it has made me gun shy about
voting in the future on any contentious topic, because I know I need to
set aside the time to 'deal with that'.  Yet those contentious topics,
are the ones where we should be encouraging as many people as possible
to vote, to make sure that we have a broad spectrum of views and that it
is the 'will of the community' as it were.   And (at least in the US) is
against the idea in general of voter confidence.  Where you are free to
hold your belief without needing to be slammed for it publicly.

So anyway, that's one reason.  Whether it's a good reason or not is up
to others to decide.


... But it may be preferable to hide the Person<->Vote table until the
vote is over. That would provide protection against harassment to win
someone over and change his/her vote.


Unfortunately that won't stop the above situation.  While it would stop
the idea of campaigning someone to change their vote (which is perhaps
another reason to do it).  It just means all the above issues would be
taking place post-vote, instead of during-vote.

Eli



That's the reason why I suggested anonymous votes once again.

On few occasions, it happened that I didn't vote on an RFC because I 
didn't want the RFC author to see how I voted. That may look strange but 
one may have lots of reasons not to want his vote to go public.


Sure, in an ideal world, we should stand by our decision and be ready to 
defend it with pure technical arguments, whatever relationship we have 
with the RFC author. Unfortunately, that's not always the case and the 
STH saga proved that, at least in this case, a lot of people, like Eli, 
 would have felt more comfortable if votes had been anonymous. Anyway, 
the course of the vote would have been very different.


I must say I don't understand why people want individual votes to be 
public, even after the vote is over. The mailing list is here for 
eveyone to expose arguments. IMO, the vote is a place for privacy. I 
definitely *don't* want an RFC author to ask me why I voted against his 
proposal, and I will certainly *never* do that on one of my RFCs. If I 
have something to say, I will say it on the list. My vote is my private 
decision and I don't have to justify it against anybody.


Actually, that's nothing else than the rules already applied in every 
elections in democratic states. Would you approve everyone to know who 
you voted for after a presidential election ? Someone said that 
registers are used to keep a track of who voted. That's right but the 
information is here to avoid mutiple votes and is not publicly 
available. So, even the voters' names are not disclosed. I just suggest 
we do the same, ensuring votes cannot be biased by non-technical 
considerations.


A case that could be prevented by public votes is the RFC being 
massively rejected while almost no objections were done on the ML. In 
this case, we could argue that the RFC author could use the vote 
information to get more information from voters. Unfortunately, that 
case already happened with Stas' (great :) RFC about default class 
constructor, which demonstrated that public votes are not an efficient 
protection against this. IMHO, the solution to such case is not a 
question of public/private vote. It is more due to the fact that many 
list members don't read the RFCs before vote starts. So, the discussion 
phase is almost empty and, as soon as you start the vote, 

[PHP-DEV] Status Of CoC RFC: (WAS: Adopt Code of Conduct)

[Anthony Ferrara]

All,

> If we want to deal with the reasons why people avoid internals, the let's go
> and analyze the problem first ? I will start asking whether we really want
> to attract newcomers. The question may sound ridiculous but I think we
> don't, mostly because most people here see newcomers as just a source of
> annoyment and silly questions/RFCs. Additional evidence shows that we never
> did much effort to help integrate newcomers.
>
> So, the tone on the list is, IMO, just a small part of the problem. As long
> as there's no consensus on whether we want to attract newcomers and the
> effort we're ready to do to integrate them, discussing about the details of
> a CoC seems a bit prematurate to me.

I am no longer going to participate in this email thread, as it's
ceased to be productive to any degree.

Keep in mind, the purpose of the thread is to work on the draft
proposal to guide it to a final state which would be proposed
officially (which it hasn't yet been). When the time comes that the
proposal is officially presented for discussion, arguments for and
against it can be made. But at this point, arguments are being
presented for a moving target and as such are more of a distraction
than constructive.

I will continue to work on this RFC. If you would like to have a
constructive discussion, please come find me. But I am not going to
tolerate this distraction that has absolutely nothing to do with the
proposal anymore. Yak-Shaving and Sea-Lioning have taken over the
discussion thread and led to absolutely nothing constructive in the
past 100+ replies.

If you would like to be constructive and help guide the proposal to
something that will work, feel free to reach out to me personally and
I will honor any constructive request. Some of us are meeting with
some of the people behind Drupal's CoC to collaborate on it. I expect
that discussion will drive the proposal significantly.

I expect that my next post on this subject will be presenting a final
proposal that I intend to open for voting after the required
discussion period.

Anthony

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

Re: [PHP-DEV] Re: Anonymous voting on wiki

[Yasuo Ohgaki]

Hi all,

On Sun, Jan 10, 2016 at 7:29 PM, Andreas Heigl  wrote:
>> From my own point of view, I like to know who supports and who opposes a
>> particular RFC simply because I can't vote myself. It helps me to decide
>> if I need to look deeper into the RFC or if I can rely on those with
>> voting rights that I trust to get it right. We should not have to hide
>> our views so the idea that anonymity is a right is part of the problem
>> in the modern world? Part of the reason for now needing a CoC?
>
> Thank you Lester for expressing that view. I am not really sure about
> anonymous voting myself. I can understand that anonymous voting is a
> good idea *during the voting phase* but I am strongly against
> withholding the names of the voters as well as their vote *after the
> voting ends*.

I support this idea.
It should be public after voting ends at least.

Regards,

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

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

Re: [PHP-DEV] PHP 7.1 - Argon2

[Scott Arciszewski]

On Mon, Jan 11, 2016 at 11:32 AM, Solar Designer  wrote:
>
> On Mon, Jan 11, 2016 at 10:04:36AM -0500, Anthony Ferrara wrote:
> > To my understanding, the crypt scheme hasn't been formalized. Solar
> > Designer, can you confirm?
>
> I think it has been, in the way defined by encoding.c in:
>
> https://github.com/P-H-C/phc-winner-argon2
>
> $ echo password | ./argon2 salt | grep ^Encoded
> Encoded: 
> $argon2i$m=4096,t=3,p=1$c2FsdA$pDVCkCwe3h2SnqGPAGNoM36WzhyGPAd+bb3BLrxyzWw
> $ echo password | ./argon2 salt -d | grep ^Encoded
> Encoded: 
> $argon2d$m=4096,t=3,p=1$c2FsdA$Js0T8jeqwDeja/AQ+x2o4SUn22MofUW2f88RlMRhQso
>
> I haven't been involved in this closely, though.
>
> Alexander

I'm going to write the pull request tonight then. If there's any
reason to not merge it, please discuss it there.

Thanks Solar. :)

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] [RFC] [Draft] Adopt Code of Conduct

[François Laupretre]

Le 11/01/2016 23:55, Anthony Ferrara a écrit :


There are two prime reasons people may avoid internals (at least
related to this discussion).

1. Don't want to deal with the aggressive tone of the list
2. Don't want to expose themselves to targeted aggression/negativity


If we want to deal with the reasons why people avoid internals, the 
let's go and analyze the problem first ? I will start asking whether we 
really want to attract newcomers. The question may sound ridiculous but 
I think we don't, mostly because most people here see newcomers as just 
a source of annoyment and silly questions/RFCs. Additional evidence 
shows that we never did much effort to help integrate newcomers.


So, the tone on the list is, IMO, just a small part of the problem. As 
long as there's no consensus on whether we want to attract newcomers and 
the effort we're ready to do to integrate them, discussing about the 
details of a CoC seems a bit prematurate to me.


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

[Zeev Suraski]

> > That's because nobody does that. Instead, the question is whether the
> > specific proposal is helpful to fix specific issues. The conversation
> > goes like this:
> >
> > A: here's solution X!
> > B: for what?
> > A: for problem Y
> > B: but do we have problem Y? Also, X does not seem to solve Y and also
> > introduces problem Z
> > A: we can solve Z easily! Also, here's proof problem Q exists.
> > B: but Q is not Y. And we didn't see Y exists so far. And your
> > solution to Z sounds iffy.
> > A: why you keep denying problem Q exists?!
> 
> I don't think that's a fair characterization of this discussion.

Fair or not, there's clearly confusion regarding what this RFC aims to achieve, 
and this confusion is widespread.  More on that below.

> Some people have
> questioned what this is a solution to, but most haven't.
> Some have questioned if we have a problem, but most haven't.

What clearly hasn't happened is any proponent of this RFC actually answering 
these questions.

I wouldn't assume that because most people aren't participating in this 
discussion (and most people aren't), all the silent voice aren't interested in 
getting answers to these questions.  I'm sure some are waiting for these 
questions to be answered, like me.

> Most of the constructive discussion (meaning the discussion not using
> hyperbole or overloaded terms) has been not talking about if we need to do
> something, but if what is proposed is good or not. And the best parts have
> been help molding the proposal to be better overall.

Is my email being ignored because I used the word 'judicial' to describe the 
current RFC, and differentiate it from a regular CoC+mediation? 
Is it non constructive or hyperbole in your opinion?

> Actually, asking for proof and denying are the same thing. If they weren't,
> then why would you be asking for proof unless you believed it didn't
> happen?

Asking for proof is not at all the same as denying it exists. 
Not knowing that something exists, and even finding it difficult to believe it 
does - is not the same as knowing that it doesn't exist / denying it.
 
What I said is that despite numerous  situations I've been involved in 
controversial discussions, I've never once witnessed what I would categorize as 
a threat of violence against me, nor did I witness one against another person.  
So despite having very relevant experience and a very long track record, I 
don't *know* it exists.  I, of course, cannot rule out that it does exist, but 
can certainly not be sure it does - it being statements that I would categorize 
as threats of violence.  Again, my worry here is that hyperbolic interpretation 
of text that perceives reasonable, perhaps ugly criticism as a threat of 
violence.  And since we're seeing zero examples of what constitutes a threat of 
violence - if & when the RFC is in place, some people may find they've gotten a 
lot more than they bargained for.

FWIW for threats of violence, I think I'd be willing to live with the measures 
detailed in the RFC, especially if we had some real world examples to make sure 
we're all on the same page.  But given that it goes much further than that 
(including open ended things like personal attacks, insulting and even 
harassment, given the broad interpretation that seems to be given to this word 
by many on this list) - it's problematic, and is the source of the 'censorship' 
fears.  I'm sure some could consider this letter as a personal attack of sorts. 
 Some may consider a person saying 'That's not true' as a personal attack of 
sorts, since it's the equivalent of calling one a liar.  And the list goes on.

Last but not least, if I understood you correctly on Twitter, the goal of the 
RFC isn't to change the vibes on internals:
Zeev:  "I'm waiting to hear about how the CoC would apply to the 'poison that 
actively hurts the project' with real life examples."
Anthony:  "as I have said before, that is not a goal of the CoC. I said it 
because you (and Stas) said argument was fine and good."

I, for one, haven't seen this mentioned explicitly on list, but more 
importantly - there's clearly a lot of confusion both on the list and on 
Twitter regarding what this RFC aims to achieve.  A lot of people on Twitter 
pinged me (and you) saying how the way internals is discourages them to get 
involved (can provide references if needed), and it's very clear they believe 
the CoC will change that.  Can you send a public message that it won't, or 
explain to all of us how it will?

Thanks,

Zeev

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

[David Zuelke]

On 11.01.2016, at 12:31, Anthony Ferrara  wrote:

> Actually, asking for proof and denying are the same thing. If they
> weren't, then why would you be asking for proof unless you believed it
> didn't happen?

They are not the same thing. If you make a claim, then the onus of proof is on 
you, and you cannot simply turn that reasonable request against them by then 
implying they're denying. Otherwise, why have proof for anything at all?

To me, this begs the question: would you handle incidents covered by the CoC in 
a similar way, with that same attitude? An accuser claims something, and asking 
for proof will be interpreted as denial?

By extension, will a third party asking for proof for an incident be subject to 
kafkatrapping - "the fact that you're doubting X happened means you're also 
guilty of X"? That one has happened to me before on twitter. Didn't stick 
because of the ridiculousness, but maybe the conjured mob was simply not large 
enough to spark sufficient outrage.

I'm pretty uncomfortable that you as the person "in charge" of this RFC hold 
such biased views. If you can't see that asking for proof and denial are 
different things then that IMO disqualifies you for that role.

The same applies to your claims of threats of violence. It's fine if you don't 
want to provide details, but then you can't bring those cases up. It's 
legitimate for others here to ask you for evidence if you do bring it up. I 
understand that we're all different personalities and you're maybe more wired 
in that direction (mentioning something in passing), but you need to understand 
that once a claim is out there, it's up to you to back it up. If you then 
refuse to, it raises doubts, and rightfully so.

Otherwise, we "just have to take your word for it", and that's exactly the 
thing many here are afraid of when it comes to this RFC - that in the future, 
anyone can pull accusations out of their hats, and the accusation is enough, 
because "why would you be making that accusation if it didn't happen" (please 
compare that sentence to the quoted section at the beginning of this message to 
understand why it is relevant.

David


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

[Lester Caine]

On 11/01/16 22:55, Anthony Ferrara wrote:
> There are two prime reasons people may avoid internals (at least
> related to this discussion).
> 
> 1. Don't want to deal with the aggressive tone of the list
> 2. Don't want to expose themselves to targeted aggression/negativity

Sorry, but this is bullshit ...
And I say that as someone who's comments have been shouted down here in
the past, but my views have never been censured and reading the list
regularly I do not recognise EITHER of those statements. No CoC is going
to change the manor my objections to the way PHP is developing are
addressed, but as long as the 1.5+ million lines of PHP code I'm using
remains working I'm not worried and will not waste any time discussing it.

What people talk about on other media such as Twitter, Facebook,
Google+, Linkedin, and so on is not something the PHP project has any
influence over and winging there is not the place to register a problem?

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

> I don't think that's a fair characterization of this discussion. Some
> people have questioned what this is a solution to, but most haven't.
> Some have questioned if we have a problem, but most haven't.

Again, "a problem". You and Pierre are talking as if there's specific
problem you have already identified, and there are people agreeing that
it exists and those that still deny it exists. But it's not the case -
we don't even know what *is* that problem. Is that harassment? On the
list? Off list? Aggressive discussion on list? Reputation of the list
being unfriendly, regardless of what actually happens? What "a problem"
is that you are fixing? I still don't know. It may be crystal clear to
you and Pierre, but so far I don't think you succeeded in explaining it.

> Actually, asking for proof and denying are the same thing. If they
> weren't, then why would you be asking for proof unless you believed it
> didn't happen?

Well, I honestly don't know how to react to this. It's just not. I can't
believe you are seriously saying this. I'm sorry if I'll get a bit to
deep into the woods here, but I honestly never expected reading
something like that. The whole structure of science, mathematics and
logic is built on the concept of proof, moreover, the whole concept
underlying this - that there are facts, knowable laws of nature, that
reason and logic are possible, etc. - are based on these concepts, and
nowhere it is equated with denial. People have been looking for proof
for Fermat's Last Theorem for over 350 years - were they all denying its
veracity for all that time? Of course not. In fact, most of them were
sure it is true. But opinion and proof are not the same.

You seem to be under impression that there can be only two stances with
relation to some claim - either completely and unquestionably
acknowledging it as the holy truth, or completely denying it. This is
actually not so - for most claims, it is rarely one of these, and for
claims that have not been substantiated, the right relation is "we do
not know anything about the validity of this claim". Proof is the one
that helps us move from "no idea" to "it's probably so" or "I'm as sure
in it as I ever been in anything" or "looks very fishy, it's probably
completely bogus", etc.

I now start to think maybe the trouble you have understanding why people
have problems with the structure you propose stems from this
misunderstanding - you seem to think there are only hard obvious facts
which one either accepts or denies, and merely asking for proof is the
same as denial, since it's not acceptance - either it is true, and then
we need no proof, or it's false, and then any "proof" is just lies. Of
course, in reality we would not deal with anything like that - we'd only
deal with claims of unknown veracity, for which we would have to ask for
proof. With your approach, of course, that would be denying the
experience of the person who complained, which is IMO unacceptable - how
you can deny somebody's experience - so I wonder how you imagined a
resolution team would work?

> As far what exactly "these problems" are specifically, that's an
> entirely different discussion than the one we've been having here as
> part of the CoC. Because the vast majority of "these problems" aren't
> the goal of the CoC. The goal of the CoC to me is to help create a
> safe place. To create a mechanism and reinforcement that we should all
> behave appropriately.

But what is a "safe place" we are trying to create (note: that's one of
the reasons I wanted more positive CoC)? I would be glad to help all I
can to do this, but for that I assume I'd need to know what I am trying
to do? How we know if we created this place or utterly failed in it?
Let's say we did create that "safe place" - could you describe any
specific difference with what is happening on the list now? For example,
if somebody were given the archive of the list pre-safe-place and
post-safe-place, they would be able to distinguish which is which using
that criteria? What we would have more of, what we would have less of,
what we would stop seeing here and what would we start seeing here?

> Other issues (such as over aggressiveness on the list, etc) are out of
> scope right now, so aren't worth discussing *in this thread*. Feel
> free to discuss it as much as you want in another thread, but I'd like
> to see this one get back to constructively discussing the proposal.
> Well, not really "get back to", but "start".
> 

I think we started long ago. And the question if style of discussion on
the list would *ever* be in scope for CoC, is very much relevant to it,
especially as the problems with this style was repeatedly pointed to as
the primary reason why we need the CoC.
Once we have created those powers that you require, we can not (at least
not without a lot of drama) un-create them, so I think it is prudent to
know what these powers are to be used for.
Note that I and others - again, very much in scope of 

Re: [PHP-DEV] PHP 7.1 - Argon2

[Pierre Joye]

On Jan 12, 2016 6:28 AM, "Scott Arciszewski"  wrote:
>
> On Mon, Jan 11, 2016 at 11:32 AM, Solar Designer 
wrote:
> >
> > On Mon, Jan 11, 2016 at 10:04:36AM -0500, Anthony Ferrara wrote:
> > > To my understanding, the crypt scheme hasn't been formalized. Solar
> > > Designer, can you confirm?
> >
> > I think it has been, in the way defined by encoding.c in:
> >
> > https://github.com/P-H-C/phc-winner-argon2
> >
> > $ echo password | ./argon2 salt | grep ^Encoded
> > Encoded:
$argon2i$m=4096,t=3,p=1$c2FsdA$pDVCkCwe3h2SnqGPAGNoM36WzhyGPAd+bb3BLrxyzWw
> > $ echo password | ./argon2 salt -d | grep ^Encoded
> > Encoded:
$argon2d$m=4096,t=3,p=1$c2FsdA$Js0T8jeqwDeja/AQ+x2o4SUn22MofUW2f88RlMRhQso
> >
> > I haven't been involved in this closely, though.
> >
> > Alexander
>
> I'm going to write the pull request tonight then. If there's any
> reason to not merge it, please discuss it there.
>
> Thanks Solar. :)

That's great :)

And as it will not be enabled by default the risk of having to maintain our
own prefix can be minimized by adding a note stating the current situation.

Thanks :)

Re: [PHP-DEV] mcrypt extermination plan

[Ferenc Kovacs]

2016. jan. 10. 12:57 ezt írta ("Marco Pivetta" ):
>
> While I'd love to see mcrypt die, unless we all forgot how semver works,
> this isn't how it can be done :-\
> If you want to actually drop something, regardless of how bad it is (and I
> know mcrypt is bad), then the next major version is where this should
> happen.
> Note that pushing for an earlier 8.0 is not a problem either.

For the record our release process (https://wiki.php.net/rfc/releaseprocess)
explicitly states that extension support can be ended/moved to pecl in a
minor version.

Re: [PHP-DEV] PHP 7.1 - Argon2

[Rouven Weßling]

> On 11 Jan 2016, at 07:57, Scott Arciszewski  wrote:
> 
> Does adding Argon2 as a possible choice for password_hash() +
> password_verify() need an RFC? Or can I just submit a pull request?

The original RFC (https://wiki.php.net/rfc/password_hash) contained the 
following text:

> I'd propose the following policy for updating the default hashing algorithm 
> in future releases of PHP.
> 
> * Any new algorithm must be in core for at least 1 full release of PHP prior 
> to becoming default. So if scrypt is added in 5.5.5, it wouldn't be eligible 
> for default until 5.7 (since 5.6 would be the full release). But if jcrypt 
> (making it up) was added in 5.6.0, it would also be eligible for default at 
> 5.7.0.
> * The default should only change on a full release (5.6.0, 6.0.0, etc) and 
> not on a revision release. The only exception to this is in an emergency when 
> a critical security flaw is found in the current default.
> * For a normal (non-emergency) change in default, an RFC shall be issued for 
> the update of the default algorithm, following normal RFC rules.

So technically I don’t think it would be necessary to have an RFC to add 
another algorithm, though I think it might be nice as this is certainly a place 
where things shouldn’t be changed willy nilly. 

> It won't be changing the default in 7.1, and IIRC this sort of change
> was already agreed upon as part of the original password_hash() RFC.

I’m not really qualified to discuss the merits of the algorithm but a couple of 
questions:

* Is there already a crypt scheme for Argon2? Or are there any efforts to 
define one? It would good if PHP wouldn’t be an island.
* Back in July, when it won the PHC, it wasn’t deemed production ready as they 
wanted to make a few tweaks. Is that completed?
* Are you proposing to use Argon2d or Argon2i?

Lastly, I think it would be a good start to implement Argon2 in ext-hash.

Best regards
Rouven
--
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 Mon, Jan 11, 2016 at 9:48 AM, Stanislav Malyshev 
wrote:

> Hi!
>
> > Even without that, though, it's clear we *do* have more serious issues
> > than just "rudeness".  When a major contributor is getting death-threats
> > over an RFC, *there is a problem*.  That they're happening off-list
> > doesn't change the fact that *that is a problem*.
>
> OK, so to evaluate solution to a problem we need to see:
> 1. There is a problem
> 2. Solution is possible to implement
> 3. Solution solves the problem.
> 4. Solution does not produce the effects worse than the original problem
>
> Now, do we have the problem that internals is not the nicest place in
> the world? Definitely. Does CoC as solution solve it? Possibly, if we
> apply it really extensively and ban all people that cause anybody to
> feel any discomfort. That would kill any substantial discussion on the
> list.
>
> Do we have a problem with harassment outside internals (taken broadly)?
> We do. Can we make CoC that would prevent it? Nope.
>
> So, we have a situation where we have a mismatch between a problem and a
> solution, and that is what the misunderstanding is based on. You and
> several other people try to prove something we already agree about -
> that certain problems exist - and forget to prove something that needs
> to be proven - that what you propose would solve *these* problems in any
> acceptable way. Instead, the solution (at least part of it) is designed
> to solve *different* problems, which nobody showed we even had. This
> mismatch is an issue.
>
> > with the risk of those tools being abused.  It's not just "it's too
> > dangerous", but "it's so dangerous that we'd rather have the current
> > problem."  That is, that current problems are tolerable.
>
> They are "tolerable" by definition, since we are tolerating them right
> now :) That, of course, does not mean improvement can't be made. But for
> that, we need to actually see the path to improvement, not just "do
> something because something has to be done".
>
> > The other "contra" position is to make a CoC toothless.  The argument
>
> CoC can not have any tooth per se. It's just a promise, as I said.
> Promise does not enforce itself. People can enforce promise, in
> different ways. These ways are completely separate from the promise, and
> I think there's a lot of value in the promise itself. In fact, I think
> it is a much more significant step than figuring out how to punish
> people that break the promise.
>
> > I'll take that a step further: Having a CoC with no teeth has a higher
> > risk of abuse than it having teeth, because those who would abuse it can
> > use that lack of teeth to their advantage.
>
> If you talking about insulting people on twitter and reddit, I do not
> see how any tooth to CoC would change anything. We can't ban people from
> twitter and reddit (thankfully).
>
> > At the same time, though, if someone is being maliciously hostile what
> > great cover!  A private email is not a PHP-Group managed resource, so no
> > rules!  Twitter, ha, no rules!  Reddit?  LOL like they enforce
>
> That's not true. The fact that PHP community does not enforce these
> rules, does not mean there are no rules at all. It just means we do not
> have responsibility to enforce them. We are not Team PHP World Police.
>
> I could be OK with looking into matters directly related to RFCs and
> alike discussions - but phrasing like "PHP business" open to obvious
> trolling like "what do you mean heinous acts of $Person to support
> position $whatever is not your business? Are you $whatever-ist?
> Obviously you are, and I just finished an article for $MajorNewspaper
> declaring PHP Group is a nest of $whatever-ists and I'll click "Send"
> unless you agree to make it your business right this second". So we need
> to be clear we never promised to get into this.
>
> > infrastructure".  It's trivial to circumvent otherwise.  Now, how do we
>
> It is trivial to circumvent anyway. Twitter and reddit as both
> pseudonymous.
>
> > Let's all focus on maximizing the benefit and minimizing the risk.
> > Pretending that the status quo is oh-so-wonderful accomplishes neither
> > goal.
>
> I don't think anybody pretends oh-so-wonderful. But, see the four points
> above. Having *some* solution is not enough. It needs to be *good*
> solution. Going back to the pill analogy, if you're sick, raiding the
> medicine cabinet and trying random pills may not be a good idea. And
> saying that does not mean denying that somebody feels unwell - it just
> means finding the right pill is a good idea before swallowing it.
> --
> Stas Malyshev
> smalys...@gmail.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
I think that you are ignoring a bunch of points from those supporting the
CoC.

OK, so to evaluate solution to a problem we need to see:
1. There is a problem

there are more than one problem, currently we have 

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

[Stanislav Malyshev]

Hi!

> Even without that, though, it's clear we *do* have more serious issues
> than just "rudeness".  When a major contributor is getting death-threats
> over an RFC, *there is a problem*.  That they're happening off-list
> doesn't change the fact that *that is a problem*.

OK, so to evaluate solution to a problem we need to see:
1. There is a problem
2. Solution is possible to implement
3. Solution solves the problem.
4. Solution does not produce the effects worse than the original problem

Now, do we have the problem that internals is not the nicest place in
the world? Definitely. Does CoC as solution solve it? Possibly, if we
apply it really extensively and ban all people that cause anybody to
feel any discomfort. That would kill any substantial discussion on the
list.

Do we have a problem with harassment outside internals (taken broadly)?
We do. Can we make CoC that would prevent it? Nope.

So, we have a situation where we have a mismatch between a problem and a
solution, and that is what the misunderstanding is based on. You and
several other people try to prove something we already agree about -
that certain problems exist - and forget to prove something that needs
to be proven - that what you propose would solve *these* problems in any
acceptable way. Instead, the solution (at least part of it) is designed
to solve *different* problems, which nobody showed we even had. This
mismatch is an issue.

> with the risk of those tools being abused.  It's not just "it's too
> dangerous", but "it's so dangerous that we'd rather have the current
> problem."  That is, that current problems are tolerable.

They are "tolerable" by definition, since we are tolerating them right
now :) That, of course, does not mean improvement can't be made. But for
that, we need to actually see the path to improvement, not just "do
something because something has to be done".

> The other "contra" position is to make a CoC toothless.  The argument

CoC can not have any tooth per se. It's just a promise, as I said.
Promise does not enforce itself. People can enforce promise, in
different ways. These ways are completely separate from the promise, and
I think there's a lot of value in the promise itself. In fact, I think
it is a much more significant step than figuring out how to punish
people that break the promise.

> I'll take that a step further: Having a CoC with no teeth has a higher
> risk of abuse than it having teeth, because those who would abuse it can
> use that lack of teeth to their advantage.

If you talking about insulting people on twitter and reddit, I do not
see how any tooth to CoC would change anything. We can't ban people from
twitter and reddit (thankfully).

> At the same time, though, if someone is being maliciously hostile what
> great cover!  A private email is not a PHP-Group managed resource, so no
> rules!  Twitter, ha, no rules!  Reddit?  LOL like they enforce

That's not true. The fact that PHP community does not enforce these
rules, does not mean there are no rules at all. It just means we do not
have responsibility to enforce them. We are not Team PHP World Police.

I could be OK with looking into matters directly related to RFCs and
alike discussions - but phrasing like "PHP business" open to obvious
trolling like "what do you mean heinous acts of $Person to support
position $whatever is not your business? Are you $whatever-ist?
Obviously you are, and I just finished an article for $MajorNewspaper
declaring PHP Group is a nest of $whatever-ists and I'll click "Send"
unless you agree to make it your business right this second". So we need
to be clear we never promised to get into this.

> infrastructure".  It's trivial to circumvent otherwise.  Now, how do we

It is trivial to circumvent anyway. Twitter and reddit as both
pseudonymous.

> Let's all focus on maximizing the benefit and minimizing the risk.
> Pretending that the status quo is oh-so-wonderful accomplishes neither
> goal.

I don't think anybody pretends oh-so-wonderful. But, see the four points
above. Having *some* solution is not enough. It needs to be *good*
solution. Going back to the pill analogy, if you're sick, raiding the
medicine cabinet and trying random pills may not be a good idea. And
saying that does not mean denying that somebody feels unwell - it just
means finding the right pill is a good idea before swallowing it.
-- 
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

[Adam Howard]

First and foremost, as PHP is an open source project and the lifeblood of
any open source project is accepting that people do come (and go).  I've
been watching internals for a few years and that is clearly obvious.  So it
seems silly for any open source project to argue against newcomers.

On Mon, Jan 11, 2016 at 9:46 PM, John Bafford  wrote:

>
> > On Jan 11, 2016, at 19:40, François Laupretre  wrote:
> >
> > If we want to deal with the reasons why people avoid internals, the
> let's go and analyze the problem first ? I will start asking whether we
> really want to attract newcomers. The question may sound ridiculous but I
> think we don't, mostly because most people here see newcomers as just a
> source of annoyment and silly questions/RFCs. Additional evidence shows
> that we never did much effort to help integrate newcomers.
> >
> > So, the tone on the list is, IMO, just a small part of the problem. As
> long as there's no consensus on whether we want to attract newcomers and
> the effort we're ready to do to integrate them, discussing about the
> details of a CoC seems a bit prematurate to me.
>
>
> I agree with this 100%.
>
> This is yet another example of the toxic internals problem. Regardless of
> one's views on the CoC proposal, the conduct of php-internals as a whole
> has been reprehensible.
>
> Whether anyone agrees with that statement or not is almost besides the
> point. Internals has a *reputation* for being toxic, and whether or not
> that reputation is justified, *it exists*, and internals is not doing
> anything to counter that reputation. Certainly not with the CoC discussion.
>
> I have watched internals for probably ten years now. I have *never* gotten
> the impression that internals was actually seriously interested in
> cultivating newcomers. Lip service is paid from time to time, but at the
> end of the day, nothing ever changes.
>
> So let's say, hypothetically, internals actually, seriously, wants
> newcomers.
>
> I've used C since 1997, PHP since 1999, come from a CS background, and PHP
> is my favorite language (well, maybe it's a tie with Objective-C). At
> least, it's the language I use most often, so I have a vested interest in
> helping it get better. I am exactly the sort of person internals should be
> courting to join the "team".
>
> And *every* time I start to think, "ok, I'm finally going to dust off
> those old patches and write some RFCs" this shit happens, and I reconsider
> and go back to lurk mode because I have no interest in participating in
> conversations about facists, whether real or imagined.
>
> I've got one RFC under discussion, and another one in draft that should be
> ready for discussion soon. Hell, I had been collecting emails for a few
> weeks and was just about to start work on (what I had hoped would be an
> ongoing series of) a weekly summary of internals (similar to what Pascal
> Martin had been doing in 2014) as an excuse to actually read all of
> internals to help wrap my head around what was actually going on from a
> tech perspective. Then the CoC thing blows up, and it's all so
> disheartening. Makes me question whether putting in the effort was worth
> it, and well, you can forget about anyone trying to write an impartial
> summary of the CoC discussion.
>
> And that's just internals. There's also apparently twitter and reddit
> flamewars and namecalling going on that I'm just as happy to know nothing
> about.
>
> This is getting a bit ranty. But internals deserves it. You all may be
> great programmers, but in terms of making people *want* to work on php-src,
> you're shitty salespeople.
>
> The reputation for internals being toxic surely bleeds over to everyone
> else who knocks PHP as being a shitty language. Only now, they get to say,
> "what a bunch of amateurs, the language devs can't even discuss a code of
> conduct without calling each other nazis".
>
> Stop the nonsense. Get better, grow up, treat each other with respect, and
> act like the adults you are. I'd like to work with you all, but you make it
> dammned hard to want to.
>
> -John
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

[PHP-DEV] Internals and Newcomers and the Sidelines (WAS: Adopt Code of Conduct)

[John Bafford]

[Apologies for the re-post; I’m re-sending this with a new subject because it’s 
really not about the CoC RFC.]

> On Jan 11, 2016, at 19:40, François Laupretre  wrote:
> 
> If we want to deal with the reasons why people avoid internals, the let's go 
> and analyze the problem first ? I will start asking whether we really want to 
> attract newcomers. The question may sound ridiculous but I think we don't, 
> mostly because most people here see newcomers as just a source of annoyment 
> and silly questions/RFCs. Additional evidence shows that we never did much 
> effort to help integrate newcomers.
> 
> So, the tone on the list is, IMO, just a small part of the problem. As long 
> as there's no consensus on whether we want to attract newcomers and the 
> effort we're ready to do to integrate them, discussing about the details of a 
> CoC seems a bit prematurate to me.


I agree with this 100%.

This is yet another example of the toxic internals problem. Regardless of one's 
views on the CoC proposal, the conduct of php-internals as a whole has been 
reprehensible.

Whether anyone agrees with that statement or not is almost besides the point. 
Internals has a *reputation* for being toxic, and whether or not that 
reputation is justified, *it exists*, and internals is not doing anything to 
counter that reputation. Certainly not with the CoC discussion.

I have watched internals for probably ten years now. I have *never* gotten the 
impression that internals was actually seriously interested in cultivating 
newcomers. Lip service is paid from time to time, but at the end of the day, 
nothing ever changes.

So let's say, hypothetically, internals actually, seriously, wants newcomers.

I've used C since 1997, PHP since 1999, come from a CS background, and PHP is 
my favorite language (well, maybe it's a tie with Objective-C). At least, it's 
the language I use most often, so I have a vested interest in helping it get 
better. I am exactly the sort of person internals should be courting to join 
the "team".

And *every* time I start to think, "ok, I'm finally going to dust off those old 
patches and write some RFCs" this shit happens, and I reconsider and go back to 
lurk mode because I have no interest in participating in conversations about 
facists, whether real or imagined.

I've got one RFC under discussion, and another one in draft that should be 
ready for discussion soon. Hell, I had been collecting emails for a few weeks 
and was just about to start work on (what I had hoped would be an ongoing 
series of) a weekly summary of internals (similar to what Pascal Martin had 
been doing in 2014) as an excuse to actually read all of internals to help wrap 
my head around what was actually going on from a tech perspective. Then the CoC 
thing blows up, and it's all so disheartening. Makes me question whether 
putting in the effort was worth it, and well, you can forget about anyone 
trying to write an impartial summary of the CoC discussion.

And that's just internals. There's also apparently twitter and reddit flamewars 
and namecalling going on that I'm just as happy to know nothing about.

This is getting a bit ranty. But internals deserves it. You all may be great 
programmers, but in terms of making people *want* to work on php-src, you're 
shitty salespeople.

The reputation for internals being toxic surely bleeds over to everyone else 
who knocks PHP as being a shitty language. Only now, they get to say, "what a 
bunch of amateurs, the language devs can't even discuss a code of conduct 
without calling each other nazis".

Stop the nonsense. Get better, grow up, treat each other with respect, and act 
like the adults you are. I'd like to work with you all, but you make it dammned 
hard to want to.

-John

-- 
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] Throwable and Error exceptions break existing PHP 5.x code

[Andrea Faulds]

Hi Adam,

Adam Harvey wrote:

On 11 January 2016 at 06:05, Rowan Collins  wrote:

Since set_exception_handler() is intended as a last-ditch "something's gone
very wrong" function anyway, I think it receiving all Throwables makes
sense, even if the BC break in your scenario is unfortunate.


Agreed entirely (as I also said last time this came up). I also don't
want a third path involving a set_throwable_handler() or similar; we
have one too many error handling paths already.

One problematic thing that we _can_ help mitigate is that the first
section of the backward incompatible changes page in the manual starts
with the changes to error and exception handling, but never mentions
this specific issue (type declarations on the exception handler
breaking). That's entirely my fault (I've mentioned it enough in
conference talks that I guess I thought I'd documented it, but
hadn't), and I'll go fix that now.


Since functions like that no longer concern just exceptions, but now the 
broader notion of "throwables", perhaps they should be renamed? It would 
make sense to me if it were now set_throwable_handler(), with an alias 
in place for the old name to avoid breaking compatibility.


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

[John Bafford]

> On Jan 11, 2016, at 19:40, François Laupretre  wrote:
> 
> If we want to deal with the reasons why people avoid internals, the let's go 
> and analyze the problem first ? I will start asking whether we really want to 
> attract newcomers. The question may sound ridiculous but I think we don't, 
> mostly because most people here see newcomers as just a source of annoyment 
> and silly questions/RFCs. Additional evidence shows that we never did much 
> effort to help integrate newcomers.
> 
> So, the tone on the list is, IMO, just a small part of the problem. As long 
> as there's no consensus on whether we want to attract newcomers and the 
> effort we're ready to do to integrate them, discussing about the details of a 
> CoC seems a bit prematurate to me.


I agree with this 100%.

This is yet another example of the toxic internals problem. Regardless of one's 
views on the CoC proposal, the conduct of php-internals as a whole has been 
reprehensible.

Whether anyone agrees with that statement or not is almost besides the point. 
Internals has a *reputation* for being toxic, and whether or not that 
reputation is justified, *it exists*, and internals is not doing anything to 
counter that reputation. Certainly not with the CoC discussion.

I have watched internals for probably ten years now. I have *never* gotten the 
impression that internals was actually seriously interested in cultivating 
newcomers. Lip service is paid from time to time, but at the end of the day, 
nothing ever changes.

So let's say, hypothetically, internals actually, seriously, wants newcomers.

I've used C since 1997, PHP since 1999, come from a CS background, and PHP is 
my favorite language (well, maybe it's a tie with Objective-C). At least, it's 
the language I use most often, so I have a vested interest in helping it get 
better. I am exactly the sort of person internals should be courting to join 
the "team".

And *every* time I start to think, "ok, I'm finally going to dust off those old 
patches and write some RFCs" this shit happens, and I reconsider and go back to 
lurk mode because I have no interest in participating in conversations about 
facists, whether real or imagined.

I've got one RFC under discussion, and another one in draft that should be 
ready for discussion soon. Hell, I had been collecting emails for a few weeks 
and was just about to start work on (what I had hoped would be an ongoing 
series of) a weekly summary of internals (similar to what Pascal Martin had 
been doing in 2014) as an excuse to actually read all of internals to help wrap 
my head around what was actually going on from a tech perspective. Then the CoC 
thing blows up, and it's all so disheartening. Makes me question whether 
putting in the effort was worth it, and well, you can forget about anyone 
trying to write an impartial summary of the CoC discussion.

And that's just internals. There's also apparently twitter and reddit flamewars 
and namecalling going on that I'm just as happy to know nothing about.

This is getting a bit ranty. But internals deserves it. You all may be great 
programmers, but in terms of making people *want* to work on php-src, you're 
shitty salespeople.

The reputation for internals being toxic surely bleeds over to everyone else 
who knocks PHP as being a shitty language. Only now, they get to say, "what a 
bunch of amateurs, the language devs can't even discuss a code of conduct 
without calling each other nazis".

Stop the nonsense. Get better, grow up, treat each other with respect, and act 
like the adults you are. I'd like to work with you all, but you make it dammned 
hard to want to.

-John


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

[PHP-DEV] Re: Internals and Newcomers and the Sidelines (WAS: Adopt Code of Conduct)

[Stanislav Malyshev]

Hi!

> This is yet another example of the toxic internals problem.
> Regardless of one's views on the CoC proposal, the conduct of
> php-internals as a whole has been reprehensible.

What in your opinion was reprehensive, could you explain?

> And *every* time I start to think, "ok, I'm finally going to dust off
> those old patches and write some RFCs" this shit happens, and I
> reconsider and go back to lurk mode because I have no interest in
> participating in conversations about facists, whether real or
> imagined.

Precisely one person mentioned anything about "fascists", and pretty
much everybody agreed that was over the top and we should not use such
words. Was that reprehensible? OK, what would you do instead?

> emails for a few weeks and was just about to start work on (what I
> had hoped would be an ongoing series of) a weekly summary of
> internals (similar to what Pascal Martin had been doing in 2014) as

That would be awesome. But this is very hard work - which is why nobody
is doing it for long.

> This is getting a bit ranty. But internals deserves it. You all may
> be great programmers, but in terms of making people *want* to work on
> php-src, you're shitty salespeople.

Maybe. For myself, I'm pretty much surely a shitty salesperson. How
would you sell it instead?

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

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

[PHP-DEV] Throwable::getCode() inconsistencies

[Umberto Salsi]

Current situation from the manual:

- Interface method Throwable::getCode() promises to return int.

- The Error class and the Exception class both implement Throwable,
  but their constructor accepts $code as int while their getCode() method
  returns mixed.

The reason, reveals the Exception::getCode() manual page, is that the
getCode() method "Returns the exception code as integer in Exception but
possibly as other type in Exception descendants (for example as string
in PDOException).". Then, basically, getCode() may return anything,
then it should be declared to return "mixed".

Maybe is not too late to fix this mess, which is confusing for the user,
impossible to validate, and basically useless (nobody knew what these
int codes stand for before, now the situation is even worse).

So here is my proposal:

1. Remove the getCode() method from Throwable and Error. The "error code"
concept still remains in the Exception class for backward compatibility.

2. Specialized classes must define their specialized exceptions with their
specialized feedback informations (error codes or whatever and respective
properties and/or methods); user code that want to take advantage of the
extra infos, may catch these specialized exceptions and it knows how to
handle these data.

3. PDOException::getCode() returns 0 as any other class
extending Exception I'm aware of, and instead it may define a
PDOException::getSomethingElseFeedback() returning something useful, (and
if it is only a string, the getMessage() method already fits the need).

Regards,
 ___ 
/_|_\  Umberto Salsi
\/_\/  www.icosaedro.it


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

Re: [PHP-DEV] Throwable and Error exceptions break existing PHP 5.x code

[Adam Harvey]

On 11 January 2016 at 06:05, Rowan Collins  wrote:
> Since set_exception_handler() is intended as a last-ditch "something's gone
> very wrong" function anyway, I think it receiving all Throwables makes
> sense, even if the BC break in your scenario is unfortunate.

Agreed entirely (as I also said last time this came up). I also don't
want a third path involving a set_throwable_handler() or similar; we
have one too many error handling paths already.

One problematic thing that we _can_ help mitigate is that the first
section of the backward incompatible changes page in the manual starts
with the changes to error and exception handling, but never mentions
this specific issue (type declarations on the exception handler
breaking). That's entirely my fault (I've mentioned it enough in
conference talks that I guess I thought I'd documented it, but
hadn't), and I'll go fix that now.

Adam

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

Stas,

On Mon, Jan 11, 2016 at 3:15 PM, Stanislav Malyshev  wrote:
> Hi!
>
>> I fail to understand how one can think that the CoC could be about
>> censorship  (which is basically what this comment says).
>
> I can explain you that very easily: there are known instances where CoCs
> were used and even more instances where there were attempts to use CoCs
> and CoC-like structures exactly for that. It's not a concern because
> people think it *might* happen, it's a concern because it *already
> happened* elsewhere and people think it also might happen *here*.

Can you cite examples of where this has happened before? Perhaps
studying those incidents will reveal insights we can use to prevent
it.

>> I also fail to understand how one can fail to accept that we already had
>> and have issues, despite numerous people having experienced it.
>
> That's because nobody does that. Instead, the question is whether the
> specific proposal is helpful to fix specific issues. The conversation
> goes like this:
>
> A: here's solution X!
> B: for what?
> A: for problem Y
> B: but do we have problem Y? Also, X does not seem to solve Y and also
> introduces problem Z
> A: we can solve Z easily! Also, here's proof problem Q exists.
> B: but Q is not Y. And we didn't see Y exists so far. And your solution
> to Z sounds iffy.
> A: why you keep denying problem Q exists?!

I don't think that's a fair characterization of this discussion. Some
people have questioned what this is a solution to, but most haven't.
Some have questioned if we have a problem, but most haven't.

Most of the constructive discussion (meaning the discussion not using
hyperbole or overloaded terms) has been not talking about if we need
to do something, but if what is proposed is good or not. And the best
parts have been help molding the proposal to be better overall.

>> create a somehow useful CoC. If we do not see us having problems, there is
>> no point to even discuss a document to solve non existant (for us) problems.
>
> As I note again, talking about abstract "having problems" as an argument
> to do a specific thing is not very useful.
>
>> As a side but important note, it is very disturbing to read so many of us
>> denying the very issues we have. Even if it is denied in a very diplomatic
>> way. I am convinced that this is the first problem we must solve to get a
>> CoC, to accept the very existence of these problems.
>
> First of all, asking for proof and denying is different thing (though
> people often confuse the two, but these *are* different). Second, "very
> issues we have" is, again, very unspecific thing, so it's not even
> possible to deny it. Before I could even deny that "these problems
> exist" - or before you claim I or anybody else does - I'd like to know
> what exactly are "these problems" in specific terms. Because some of the
> problems were almost unanimously recognized, some was not, so it's not
> clear what parts we are talking about.

Actually, asking for proof and denying are the same thing. If they
weren't, then why would you be asking for proof unless you believed it
didn't happen?

As far what exactly "these problems" are specifically, that's an
entirely different discussion than the one we've been having here as
part of the CoC. Because the vast majority of "these problems" aren't
the goal of the CoC. The goal of the CoC to me is to help create a
safe place. To create a mechanism and reinforcement that we should all
behave appropriately.

Other issues (such as over aggressiveness on the list, etc) are out of
scope right now, so aren't worth discussing *in this thread*. Feel
free to discuss it as much as you want in another thread, but I'd like
to see this one get back to constructively discussing the proposal.
Well, not really "get back to", but "start".

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

[Kevin Smith]

> On Jan 11, 2016, at 2:48 AM, Stanislav Malyshev  wrote:

> 
> So, we have a situation where we have a mismatch between a problem and a
> solution, and that is what the misunderstanding is based on. You and
> several other people try to prove something we already agree about -
> that certain problems exist - and forget to prove something that needs
> to be proven - that what you propose would solve *these* problems in any
> acceptable way. Instead, the solution (at least part of it) is designed
> to solve *different* problems, which nobody showed we even had. This
> mismatch is an issue.

This is my chief concern with the proposal. We keep seeing allusions to 
problems of toxicity and tone and the like all the while being assured that the 
proposal does not seek to dictate behavior or punish people for defending their 
position passionately.

If the latter is true, what’s the use in making a case that certain people 
and/or communication channels aren’t friendly enough?
 

Kevin Smith
Hearsay Interactive 

RE: [PHP-DEV] Re: Anonymous voting on wiki

[Zeev Suraski]

> -Original Message-
> From: Stanislav Malyshev [mailto:smalys...@gmail.com]
> Sent: Sunday, January 10, 2016 12:00 AM
> To: Andrea Faulds ; internals@lists.php.net
> Subject: Re: [PHP-DEV] Re: Anonymous voting on wiki
> 
> Hi!
> 
> > This seems useful. I do wonder whether we should use by default for
> > RFCs. It's interesting to see how different people vote, and knowing
> > who
> 
> I think we talked about it, and decided not to do it. Anything changed?
> 
> > One concern I have with the patch is that it doesn't appear (by my
> > reading of the code) to show who voted. I think it's important to know
> 
> This is intentional. Otherwise by taking snapshots of the page at regular
> periods and seeing who voted and how the totals changed, one can deduce
> each personal vote.

I have no idea if it's related, but is there any chance the patch caused some 
older votes to be broken - at least in how they're displayed?
Case in point:
https://wiki.php.net/rfc/voting/vote

Zeev

[PHP-DEV] Throwable and Error exceptions break existing PHP 5.x code

[Giovanni Giacobbi]

Greetings,

Short premise before I get flamed: I know PHP 7 is rolling and it is way
too late for this, that I should've tested the RCs, follow the mailing list
and so on, but I'm a dev like you guys and struggle with the time to do
everything by the book, including reading the previous threads because I'm
pretty sure this was brought up by somebody, but as there are hundreds of
message under the "Throwable" topic and I can't read all of them.

In short I have this situation:



This happens because the specific handler will output the exception
according to the expected format (HTML, JSON, or even an image).

Now after upgrading to PHP7 when one of the new Error exception is thrown,
I get the following error:

PHP Fatal error:  Uncaught TypeError: Argument 1 passed to
SpecificHandler::exception() must be an instance of Exception, instance of
Error given, called in [...]

Having been a PHP dev for 10 years now I know that the policy is to try to
break as little as possible while implementing new features, and I like
that. I know that sometimes things must be broken to progress, but in this
case maybe there is a very simple fix that I can suggest to avoid breaking
existing code, change set_handler_exception like this:

set_exception_handler(callback function, bool also_throwables = false);

The new parameter "also_throwables" defaults to false, so the same
behaviour as before is preserved. If you want it to catch also the new PHP7
Error exceptions, you can just set it to true.

What is your take on this? I know I can easily fix my code to work on both
PHP 5.x and PHP 7.x, but I really disliked this kind of BC.

Kind regards
Giovanni

Re: [PHP-DEV] Throwable and Error exceptions break existing PHP 5.x code

[Rowan Collins]

Giovanni Giacobbi wrote on 11/01/2016 13:31:

set_exception_handler(callback function, bool also_throwables = false);

The new parameter "also_throwables" defaults to false, so the same
behaviour as before is preserved. If you want it to catch also the new PHP7
Error exceptions, you can just set it to true.


This is an interesting idea, but other than the specific transition to 
PHP 7, I'm not sure when it would be used.


Put it this way: if Errors existed when you first wrote this code, would 
you want to handle them using your custom handler functions, or would 
you prefer them to the fall through to the default server White Screen 
of Doom? My guess is that you'd want to pass them to the handler, even 
if it immediately checked "if ($e instanceOf Error)" and used a 
different output style.


Since set_exception_handler() is intended as a last-ditch "something's 
gone very wrong" function anyway, I think it receiving all Throwables 
makes sense, even if the BC break in your scenario is unfortunate.


Regards,
--
Rowan Collins
[IMSoP]

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

Re: [PHP-DEV] PHP 7.1 - Argon2

[Pierre Joye]

Hi,
On Jan 11, 2016 4:12 PM, "Rouven Weßling"  wrote:
>
>
> > On 11 Jan 2016, at 07:57, Scott Arciszewski  wrote:
> >
> > Does adding Argon2 as a possible choice for password_hash() +
> > password_verify() need an RFC? Or can I just submit a pull request?
>
> The original RFC (https://wiki.php.net/rfc/password_hash) contained the
following text:
>
> > I'd propose the following policy for updating the default hashing
algorithm in future releases of PHP.
> >
> > * Any new algorithm must be in core for at least 1 full release of PHP
prior to becoming default. So if scrypt is added in 5.5.5, it wouldn't be
eligible for default until 5.7 (since 5.6 would be the full release). But
if jcrypt (making it up) was added in 5.6.0, it would also be eligible for
default at 5.7.0.
> > * The default should only change on a full release (5.6.0, 6.0.0, etc)
and not on a revision release. The only exception to this is in an
emergency when a critical security flaw is found in the current default.
> > * For a normal (non-emergency) change in default, an RFC shall be
issued for the update of the default algorithm, following normal RFC rules.
>
> So technically I don’t think it would be necessary to have an RFC to add
another algorithm, though I think it might be nice as this is certainly a
place where things shouldn’t be changed willy nilly.
>
> > It won't be changing the default in 7.1, and IIRC this sort of change
> > was already agreed upon as part of the original password_hash() RFC.
>
> I’m not really qualified to discuss the merits of the algorithm but a
couple of questions:
>
> * Is there already a crypt scheme for Argon2? Or are there any efforts to
define one? It would good if PHP wouldn’t be an island.

https://github.com/P-H-C/phc-winner-argon2

The reference implementation. If anything we should use it.

I am not sure if we should bundle the library tho'.

> * Back in July, when it won the PHC, it wasn’t deemed production ready as
they wanted to make a few tweaks. Is that completed?
> * Are you proposing to use Argon2d or Argon2i?
>
> Lastly, I think it would be a good start to implement Argon2 in ext-hash.
>
> Best regards
> Rouven
> --
> 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

[Adam Howard]

I question if there is a way to keep all communication in PHP Internals on
PHP Internals, which would minimize the risk of someone reaching someone
outside of PHP Internals.  By that I mean, as it stands now, everyone's
email is public and someone meaning to cause or threaten harm could
personally target someone.  Would it not be better if a system was designed
to generate an anonymous email and only official PHP Team Members would
know the true identity.

Thankfully, I have never read or see any abuse within PHP Internals or
among The PHP Development.  I am somewhat surprised to read this and I too
am alarmed.  I've experienced some less than appropriate contact elsewhere,
but never within PHP.  I do not doubt the possibility, though.

On Mon, Jan 11, 2016 at 8:46 AM, Kevin Smith  wrote:

>
> > On Jan 11, 2016, at 2:48 AM, Stanislav Malyshev 
> wrote:
>
> >
> > So, we have a situation where we have a mismatch between a problem and a
> > solution, and that is what the misunderstanding is based on. You and
> > several other people try to prove something we already agree about -
> > that certain problems exist - and forget to prove something that needs
> > to be proven - that what you propose would solve *these* problems in any
> > acceptable way. Instead, the solution (at least part of it) is designed
> > to solve *different* problems, which nobody showed we even had. This
> > mismatch is an issue.
>
> This is my chief concern with the proposal. We keep seeing allusions to
> problems of toxicity and tone and the like all the while being assured that
> the proposal does not seek to dictate behavior or punish people for
> defending their position passionately.
>
> If the latter is true, what’s the use in making a case that certain people
> and/or communication channels aren’t friendly enough?
>
>
> Kevin Smith
> Hearsay Interactive 
>

Re: [PHP-DEV] Re: Anonymous voting on wiki

[Ferenc Kovacs]

On Mon, Jan 11, 2016 at 2:44 PM, Derick Rethans  wrote:

> On Sat, 9 Jan 2016, Andrea Faulds wrote:
>
> > Hi Stas,
> >
> > Stanislav Malyshev wrote:
> >
> > > Since in CoC discussion it was mentioned we may need anonymous
> > > voting, I've created a patch that allows anonymous polls to be
> > > created:
> > >
> > > https://github.com/php/web-wiki/pull/7
> > >
> > > The results still recorded per user, but everybody can see just
> > > their own vote (for logged in users) and total summary. People with
> > > shell access to the server will be able to see the votes,
> > > unfortunately I don't see how to avoid that without serious rewrite.
> > > Also, once the poll is created as anonymous it can't be turned into
> > > non-anonymous without resetting the results or manual admin action.
> > >
> > > Please review/comment. Is it's good, I propose to deploy it on
> > > wiki.php.net.
> > >
> >
> > This seems useful. I do wonder whether we should use by default for
> > RFCs. It's interesting to see how different people vote, and knowing
> > who voted which way means you can ask them what their objections were.
>
> I have gotten these question in the past, and I think it's important to
> be able to be asked why you made a specific choice.
>
> > Though, anonymous voting would mean no potential for harassing people
> > for the way they voted (though they're not necessarily free of
> > harassment for their opinion - many people make theirs public anyway).
>
> I do think that for normal RFCs, voting should not be anonymous.
>
> However, if we go that way, I find it important that once voting is
> closed, the votes are always shown (for normal RFCs) - even if chose to
> make normal RFC voting anonymous.
>
> > One concern I have with the patch is that it doesn't appear (by my
> > reading of the code) to show who voted. I think it's important to know
> > who participated in the vote, even if we don't know which way they
> > voted.
>
> I disagree, I think it is important to know who voted for what in the
> end. Some accountability is good.
>

agree, otherwise it will be very hard/impossible to notice if/when somebody
borks/manipulates the votes.

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

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

[Zeev Suraski]

Larry,

Thanks for your detailed letter.  I think that I'm not that far off from your 
position, but clearly, there are some differences of opinion that lead us to 
different conclusions.
Given the length of your email, I'm going to be very^H^H^H^H selective in what 
I respond to.

> I'm inclined to see the (partial) validity in most arguments, even if I don't
> entirely agree with them.

Same here.  In fact, being able to see things from other people's point of view 
- and being able to articulate it, even if I disagree with it, repeatedly came 
up as feedback for me over the last 20 years (yikes) of my career.

> However, it also means that extreme positions frustrate me to no end,
> because I cannot bring myself to agree with the extreme position even if it
> has valid points to make.

I actually try to understand very extreme positions too, even if I completely 
disagree with them.  Being able to understand how people reach extreme 
positions is extremely important in combating them (in case of any doubts, I'm 
*not* talking about internals at all here).

> To be clear, the "there's a risk of abuse so do nothing" crowd

I haven't seen a crowd that supports the 'do nothing' approach, at least not 
vigorously so.  The way the RFC was presented, the CoC and the ways to enforce 
it came hand in hand as one integrated, inseparable bundle.  I've yet to see 
anybody saying 'we must not do anything', even though some did argue there's no 
real need for change.  I believe most of those will be fine with a CoC that is 
a Mission Statement, or for that matter, a true Code of Conduct (which means it 
does not contain enforcement measures). 

> is saying,
> implicitly, that the known and existing problem of people getting death
> threats

Let me stop you right there.

I don't know that there have been death threats going around here.  I've never 
seen one with my own eyes, or for that matter, heard about one 2nd hand.

I don't know for a fact that there have been threats of ANY kind of violence.   
I know that Anthony reported four threats of violence, but even if he fully 
believes he was threatened with violence, I'm not sure that had we had access 
to the messages sent to him, we'd all agree that these are true threats of 
violence, or just a broad interpretation.

Given that I was presented in numerous forums as a true 'enemy of the state' 
during the STH RFC - and certainly felt that there was a mob with electronic 
pitchforks working in tandem to blame me for all sorts of things I either 
didn't do, or were completely legitimate but presented as illegitimate by 
interested parties (on internals, Twitter and Reddit)  - I now feel almost 
offended that I never once got any threats of violence, let alone death 
threats, in the context of the PHP project.  On a more serious note, yes, I 
find it difficult to believe true threats of violence were made, although I 
believe Anthony may have felt that way.

And that is exactly the problem with the judicial system.  All judicial systems 
are inherently subjective.  That's not something we can fix by working harder 
or spending more time on the RFC in my opinion (although as I told Anthony, I'm 
game for helping out - but think it's fundamentally impossible to fix).  The 
state laws we all live under are subjective, subject to abuse - and they do 
break all the time.  Even when they work out - there are different opinions 
regarding the effectiveness of the penal code, vs. rehabilitation efforts.

World history is full of examples in which certain events - real, staged or 
imaginary - were used as pretext to attack/persecute other groups.  I'm NOT 
saying this is what's happening here, definitely not purposely, but I am saying 
that it's impossible to hold the stick at both hands - if we want to take into 
account that there have been death threats or other threats of violence - which 
is mind-boggingly far-reaching from my point of view, we need to see evidence - 
not just to know whether it's true or not, but also so that we can each form 
our own opinion about them and whether they truly constitute threats or not.  
If people are not willing to present that evidence - which I fully respect and 
is entirely within their rights - I, for one, cannot accept their existence as 
evidence.  At best, it's an uncorroborated testimony - but a more accurate 
description would be 'calling for conclusion'.

> It ignores that the status quo is also subject to abuse; it's just a 
> different kind
> of abuse (taking advantage of the lack of accountability and lack of due
> process we have now), and perhaps easier to abuse by a different type of
> person.

This keeps coming up, but without any substantiated evidence that there's lack 
of accountability or that we're somehow being harmed by lack of due process.  
Not a single case has been presented for public scrutiny as a way to 'test 
drive' the CoC, despite repeated requests from David, Stas and myself (and 
perhaps others).
As 

Re: [PHP-DEV] PHP 7.1 - Argon2

[Chris Riley]

On 11 January 2016 at 09:12, Rouven Weßling  wrote:

>
> > On 11 Jan 2016, at 07:57, Scott Arciszewski  wrote:
> >
> > Does adding Argon2 as a possible choice for password_hash() +
> > password_verify() need an RFC? Or can I just submit a pull request?
>
> The original RFC (https://wiki.php.net/rfc/password_hash) contained the
> following text:
>
> > I'd propose the following policy for updating the default hashing
> algorithm in future releases of PHP.
> >
> > * Any new algorithm must be in core for at least 1 full release of PHP
> prior to becoming default. So if scrypt is added in 5.5.5, it wouldn't be
> eligible for default until 5.7 (since 5.6 would be the full release). But
> if jcrypt (making it up) was added in 5.6.0, it would also be eligible for
> default at 5.7.0.
> > * The default should only change on a full release (5.6.0, 6.0.0, etc)
> and not on a revision release. The only exception to this is in an
> emergency when a critical security flaw is found in the current default.
> > * For a normal (non-emergency) change in default, an RFC shall be issued
> for the update of the default algorithm, following normal RFC rules.
>
> So technically I don’t think it would be necessary to have an RFC to add
> another algorithm, though I think it might be nice as this is certainly a
> place where things shouldn’t be changed willy nilly.
>
> > It won't be changing the default in 7.1, and IIRC this sort of change
> > was already agreed upon as part of the original password_hash() RFC.
>
> I’m not really qualified to discuss the merits of the algorithm but a
> couple of questions:
>
> * Is there already a crypt scheme for Argon2? Or are there any efforts to
> define one? It would good if PHP wouldn’t be an island.
> * Back in July, when it won the PHC, it wasn’t deemed production ready as
> they wanted to make a few tweaks. Is that completed?
> * Are you proposing to use Argon2d or Argon2i?
>
> Lastly, I think it would be a good start to implement Argon2 in ext-hash.
>
> Best regards
> Rouven
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
I was considering the same for adding scrypt; however there (isn't|wasn't|I
couldn't find) a crypt scheme for it and having a custom algorithm
identifier for php seemed like a bad idea.

~C

Re: [PHP-DEV] Re: Anonymous voting on wiki

[Eli]

On 1/9/16 5:03 PM, Andrea Faulds wrote:
> Hi Stas,
>
> Stanislav Malyshev wrote:
>> Hi!
>>
>>> This seems useful. I do wonder whether we should use by default for
>>> RFCs. It's interesting to see how different people vote, and knowing
>>> who
>>
>> I think we talked about it, and decided not to do it. Anything changed?
>
> Actually, I don't think so. My fear was probably unfounded.

Has this discussion happened since the STH votes happened?  I know it's
been discussed before, but it seems that the STH vote kinda brought this
out of the woodwork a bit.  And honestly I haven't seen a serious
discussion about 'by default anonymous' since that time.  (But perhaps I
missed it)

Eli

-- 
|   Eli White   |   http://eliw.com/   |   Twitter: EliW   |




signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Re: Anonymous voting on wiki

[Derick Rethans]

On Sat, 9 Jan 2016, Andrea Faulds wrote:

> Hi Stas,
> 
> Stanislav Malyshev wrote:
>
> > Since in CoC discussion it was mentioned we may need anonymous 
> > voting, I've created a patch that allows anonymous polls to be 
> > created:
> > 
> > https://github.com/php/web-wiki/pull/7
> > 
> > The results still recorded per user, but everybody can see just 
> > their own vote (for logged in users) and total summary. People with 
> > shell access to the server will be able to see the votes, 
> > unfortunately I don't see how to avoid that without serious rewrite. 
> > Also, once the poll is created as anonymous it can't be turned into 
> > non-anonymous without resetting the results or manual admin action.
> > 
> > Please review/comment. Is it's good, I propose to deploy it on 
> > wiki.php.net.
> > 
> 
> This seems useful. I do wonder whether we should use by default for 
> RFCs. It's interesting to see how different people vote, and knowing 
> who voted which way means you can ask them what their objections were. 

I have gotten these question in the past, and I think it's important to 
be able to be asked why you made a specific choice.

> Though, anonymous voting would mean no potential for harassing people 
> for the way they voted (though they're not necessarily free of 
> harassment for their opinion - many people make theirs public anyway).

I do think that for normal RFCs, voting should not be anonymous.

However, if we go that way, I find it important that once voting is 
closed, the votes are always shown (for normal RFCs) - even if chose to 
make normal RFC voting anonymous.

> One concern I have with the patch is that it doesn't appear (by my 
> reading of the code) to show who voted. I think it's important to know 
> who participated in the vote, even if we don't know which way they 
> voted.

I disagree, I think it is important to know who voted for what in the 
end. Some accountability is good. 

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] Re: Anonymous voting on wiki

[Peter Cowburn]

On 11 January 2016 at 12:14, Zeev Suraski  wrote:

>
>
> > -Original Message-
> > From: Stanislav Malyshev [mailto:smalys...@gmail.com]
> > Sent: Sunday, January 10, 2016 12:00 AM
> > To: Andrea Faulds ; internals@lists.php.net
> > Subject: Re: [PHP-DEV] Re: Anonymous voting on wiki
> >
> > Hi!
> >
> > > This seems useful. I do wonder whether we should use by default for
> > > RFCs. It's interesting to see how different people vote, and knowing
> > > who
> >
> > I think we talked about it, and decided not to do it. Anything changed?
> >
> > > One concern I have with the patch is that it doesn't appear (by my
> > > reading of the code) to show who voted. I think it's important to know
> >
> > This is intentional. Otherwise by taking snapshots of the page at regular
> > periods and seeing who voted and how the totals changed, one can deduce
> > each personal vote.
>
> I have no idea if it's related, but is there any chance the patch caused
> some older votes to be broken - at least in how they're displayed?
> Case in point:
> https://wiki.php.net/rfc/voting/vote


The patch for this PR has not been merged, so no.

The linked page has been like that since April '14 and likely for some time
before then:
http://web.archive.org/web/20140411014209/https://wiki.php.net/rfc/voting/vote


>
>
> Zeev
>
>

Re: [PHP-DEV] Throwable and Error exceptions break existing PHP 5.x code

[Markus Fischer]

Dear Giovanni,

I brought this up last July, see https://bugs.php.net/bug.php?id=70050 ;
because in a few code bases I tested back then, this was the first issue
I hit.

Unfortunately, it was only deemed a "Documentation Problem" back then.
AFAIK this is the most up to date information. Sorry I don't have
further news.

cheers,
- Markus

On 11.01.16 14:31, Giovanni Giacobbi wrote:
> Greetings,
> 
> Short premise before I get flamed: I know PHP 7 is rolling and it is way
> too late for this, that I should've tested the RCs, follow the mailing list
> and so on, but I'm a dev like you guys and struggle with the time to do
> everything by the book, including reading the previous threads because I'm
> pretty sure this was brought up by somebody, but as there are hundreds of
> message under the "Throwable" topic and I can't read all of them.
> 
> In short I have this situation:
> 
>  class SpecificHandler {
>   public function exception(Exception $e) {
> .. do something very useful...
>   }
> }
> 
> function global_handler($e) {
>   SpecificHandler::exception($e);
> }
> 
> set_exception_handler("global_handler");
> ?>
> 
> This happens because the specific handler will output the exception
> according to the expected format (HTML, JSON, or even an image).
> 
> Now after upgrading to PHP7 when one of the new Error exception is thrown,
> I get the following error:
> 
> PHP Fatal error:  Uncaught TypeError: Argument 1 passed to
> SpecificHandler::exception() must be an instance of Exception, instance of
> Error given, called in [...]
> 
> Having been a PHP dev for 10 years now I know that the policy is to try to
> break as little as possible while implementing new features, and I like
> that. I know that sometimes things must be broken to progress, but in this
> case maybe there is a very simple fix that I can suggest to avoid breaking
> existing code, change set_handler_exception like this:
> 
> set_exception_handler(callback function, bool also_throwables = false);
> 
> The new parameter "also_throwables" defaults to false, so the same
> behaviour as before is preserved. If you want it to catch also the new PHP7
> Error exceptions, you can just set it to true.
> 
> What is your take on this? I know I can easily fix my code to work on both
> PHP 5.x and PHP 7.x, but I really disliked this kind of BC.
> 
> Kind regards
> Giovanni
> 

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

Re: [PHP-DEV] PHP 7.1 - Argon2

[Rouven Weßling]

> On 11 Jan 2016, at 13:27, Pierre Joye  wrote:
> 
> Hi,
> On Jan 11, 2016 4:12 PM, "Rouven Weßling"  wrote:
> >
> > * Is there already a crypt scheme for Argon2? Or are there any efforts to 
> > define one? It would good if PHP wouldn’t be an island.
> 
> https://github.com/P-H-C/phc-winner-argon2
> 
> The reference implementation. If anything we should use it.
> 
> I am not sure if we should bundle the library tho'.
> 
Thanks for the link. The included example seem to use $argon2i$ and $argon2d$ 
as crypt scheme. A cursory search didn’t show anyone else using Argon2 with a 
crypt scheme, so this would probably be good enough.

Best regards
Rouven



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

[Brandon Savage]

>
> At the same time, though, if someone is being maliciously hostile what
> great cover!  A private email is not a PHP-Group managed resource, so no
> rules!  Twitter, ha, no rules!  Reddit?  LOL like they enforce anything.
> If someone wanted to send a death threat to another developer about PHP
> business, I would hope that, as a developer, they are at least smart enough
> then to do so using a chat program that is "out of scope" so that they're
> untouchable.  (If they tried to send someone a death threat on list, we
> should ban them for stupidity. :-) )
>
> That's why the scope needs to cover "involves PHP business, regardless of
> medium" rather than "just on certain pieces of server infrastructure".
> It's trivial to circumvent otherwise.  Now, how do we define "involves PHP
> business" in a way that, for example, forbids someone from harassing a gay
> person about PHP business but doesn't penalize someone for participating in
> an anti-gay-marriage protest in their home town?  That's the question we
> should be discussing: How that balance works to minimize that risk, and
> avoid it being abused to Eich someone.  (Yes, I just used Eich's name as a
> verb.)
> 
>
>
Larry,

This is a great point, and brings up an interesting potential compromise
that might work well for solving this issue.

If the issue is that someone might take an on-list discussion and harass
someone off-list, why not limit the jurisdiction to individuals who have
participated on-list in discussion or voted on the issue?

For example, during the very heated discussion over static type hints, if
someone who had discussed the issue on Internals had then gone out to
Reddit and called Zeev a bunch of terrible things, that could be made
actionable under this code of conduct, reportable to the mediation team.

On the other hand, we have a lot of people with karma who don't always vote
and may not participate in a particular issue on-list. If two people who
have karma have a run-in outside the discussion of an issue related to PHP,
they should have to be adults and hash that out themselves.

And that to me is the crux of the issue. When it comes to making
discussions on internals more civilized, governing a person's conduct *as
it relates to their participation in the discussion* is about as far as PHP
should go. A person who is not a party to the discussion, who does not
vote, but does have karma, who happens to tweet "I think X is a moron for
proposing Y" is entitled to that opinion, *until they bring it here.*

If, on the other hand, the goal of the CoC is not to make Internals a
better place, but to govern what people in the community think, say and do
when they have no direct involvement with this group, that's another matter
entirely. And a much scarier one at that, don't you think?

Brandon

Re: [PHP-DEV] Re: Anonymous voting on wiki

[Ferenc Kovacs]

On Mon, Jan 11, 2016 at 3:25 PM, Eli  wrote:

> On 1/9/16 5:03 PM, Andrea Faulds wrote:
> > Hi Stas,
> >
> > Stanislav Malyshev wrote:
> >> Hi!
> >>
> >>> This seems useful. I do wonder whether we should use by default for
> >>> RFCs. It's interesting to see how different people vote, and knowing
> >>> who
> >>
> >> I think we talked about it, and decided not to do it. Anything changed?
> >
> > Actually, I don't think so. My fear was probably unfounded.
>
> Has this discussion happened since the STH votes happened?  I know it's
> been discussed before, but it seems that the STH vote kinda brought this
> out of the woodwork a bit.  And honestly I haven't seen a serious
> discussion about 'by default anonymous' since that time.  (But perhaps I
> missed it)
>
> Eli
>

Not sure which discussion you are referring(probably where were the
anonymous voting brought up again since the STH votes), but this pull
request was created because in the Code of Conduct thread somebody
mentioned that having anonymous votes can be useful when dealing with code
of conduct sanctions:
https://www.mail-archive.com/internals@lists.php.net/msg82537.html
where it was mentioned that previously we had hidden votes for a short
while but people complained and we reverted it:
https://www.mail-archive.com/internals@lists.php.net/msg82549.html
so Stas replied that he will be looking into porting the old patch:
https://www.mail-archive.com/internals@lists.php.net/msg82651.html
and here we are now, afaik the current PR from Stas introduces the
anonymous votes as an optional vote type which is less
intrusive/controversial than the last one, so we could merge it without
having any visible effects.
personally I wouldn't merge until we decided if we need/want the anon
votes, be that for regular RFCs (in which case I would only support the
inclusion if closing the vote makes visible who voted what) or for some
other new type of voting.

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

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

[Ferenc Kovacs]

On Mon, Jan 11, 2016 at 5:36 PM, Stanislav Malyshev 
wrote:

> Hi!
>
> > This particular case isn't what a CoC would protect. So I think that's
> > a bit of a red herring. The CoC doesn't try to enforce itself outside
> > of the scope of project members. Instead, it applies to project
>
> OK, that is clear enough, but I see an issue here - we'd be applying an
> pressure that would very quickly modify behavior towards using
> sockpuppet accounts. In fact, since we're all smart people here, I think
> one instance of enforcement would switch virtually all abuse to
> sockpuppets - why risk CoC complaints if you can make a new account with
> a witty name and vent freely?
> Which would mean if our goal were to reduce abuse, it would fail very
> fast. In fact, sockpuppets probably would be more abusive, since
> Speaking Truth To Power is so much fun.
>
> Of course, if we have clearly understood limits - such as discussion by
> project members in a project-related context - it would not hurt. I'm
> afraid it wouldn't help much either.
> --
> Stas Malyshev
> smalys...@gmail.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
https://en.wikipedia.org/wiki/Nirvana_fallacy
while what you are saying it is possible, but
1, the fact that the proposed solution doesn't solve every hypothetical
scenario doesn't mean that the solution is bad, it just means that it isn't
perfect.
2, one of the reasons for the CoC is to send a clear message that the
project doesn't support/endorse some kind of behavior, so if somebody uses
a sockpuppet while that makes it impossible for us to take any measure, but
that already made it clear that he/she doesn't talks for our project.


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

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

[Ferenc Kovacs]

On Mon, Jan 11, 2016 at 6:05 PM, Paul M. Jones  wrote:

>
> > On Jan 11, 2016, at 11:00, Brandon Savage 
> wrote:
> >
> > On Mon, Jan 11, 2016 at 11:26 AM, Anthony Ferrara 
> > wrote:
> >
> >> The CoC doesn't try to enforce itself outside
> >> of the scope of project members. Instead, it applies to project
> >> members wherever they represent the project.
> >>
> >
> > So just to be clear, your intent is for the CoC to apply *only* to those
> > who actively participate in the project.
>
> To be clear, he doesn't say "actively participate." He says only "project
> members when they represent the project."
>
> If that's to be the case, I don't recall seeing explicit definitions of
> "project member" and "represent". Perhaps I have missed them? They're
> needed so as to limit the scope-of-action to what Anthony states above.


I like how the jenkinsci folks covered the in-scope spaces under the
Community Spaces list:
https://jenkins-ci.org/conduct/#community-spaces
and they referred to their pre-existing Governance document for definition
of contributors and maintainers:
https://wiki.jenkins-ci.org/display/JENKINS/Governance+Document
In our case it is a bit easier because I don't think we have anybody who is
part of the project but not listed under http://people.php.net

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

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

[Stanislav Malyshev]

Hi!

> This particular case isn't what a CoC would protect. So I think that's
> a bit of a red herring. The CoC doesn't try to enforce itself outside
> of the scope of project members. Instead, it applies to project

OK, that is clear enough, but I see an issue here - we'd be applying an
pressure that would very quickly modify behavior towards using
sockpuppet accounts. In fact, since we're all smart people here, I think
one instance of enforcement would switch virtually all abuse to
sockpuppets - why risk CoC complaints if you can make a new account with
a witty name and vent freely?
Which would mean if our goal were to reduce abuse, it would fail very
fast. In fact, sockpuppets probably would be more abusive, since
Speaking Truth To Power is so much fun.

Of course, if we have clearly understood limits - such as discussion by
project members in a project-related context - it would not hurt. I'm
afraid it wouldn't help much either.
-- 
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 Mon, Jan 11, 2016 at 5:00 PM, Stanislav Malyshev 
wrote:

> Hi!
>
> > least hold ourselves to a level of mutual respect. Going out and
> > calling someone a moron in public is not constructive nor respectful,
> > and IMHO we as a project shouldn't sit back and blindly say "whatever"
> > if it happens.
>
> OK, so what should we do instead? So far my calls to apply some TDD were
> not heard, maybe this time?
>
> Let's consider an example of twitter user drupliconissad. It may be
> genuine individual or a troll, it doesn't matter either way.
> If you read the feed, you can find much more than "moron". Now, had we
> had CoC, what would we do? We don't know who that is, so private
> moderation is out of the question, even if we did - it's not look like a
> personal conflict that can be amicably reconciled. Should we issue a
> proclamation saying "we think some anonymous account on twitter is being
> bad"? Should we ban that person (or group of persons - we have no idea
> either way), which we have no idea who that is, from our list? Any other
> ideas?
>
>
The previous example was Phil who is a member of the PHP project, and there
is no dispute that his twitter account isn't his, that situation would be
different from this drupliconissad twitter account who is unknown to us and
probably isn't part of our project and "violated" our CoC on non php.net
related place, so you are right that we can't(and shouldn't) do about
his/her activity outside of our venues but that doesn't mean that we can't
do anything about anybody who happens to be known and part of our project.

ps: these are just examples, I'm not suggesting anything about Phil


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

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

[Anthony Ferrara]

Stas,

On Mon, Jan 11, 2016 at 11:00 AM, Stanislav Malyshev
 wrote:
> Hi!
>
>> least hold ourselves to a level of mutual respect. Going out and
>> calling someone a moron in public is not constructive nor respectful,
>> and IMHO we as a project shouldn't sit back and blindly say "whatever"
>> if it happens.
>
> OK, so what should we do instead? So far my calls to apply some TDD were
> not heard, maybe this time?
>
> Let's consider an example of twitter user drupliconissad. It may be
> genuine individual or a troll, it doesn't matter either way.
> If you read the feed, you can find much more than "moron". Now, had we
> had CoC, what would we do? We don't know who that is, so private
> moderation is out of the question, even if we did - it's not look like a
> personal conflict that can be amicably reconciled. Should we issue a
> proclamation saying "we think some anonymous account on twitter is being
> bad"? Should we ban that person (or group of persons - we have no idea
> either way), which we have no idea who that is, from our list? Any other
> ideas?

This particular case isn't what a CoC would protect. So I think that's
a bit of a red herring. The CoC doesn't try to enforce itself outside
of the scope of project members. Instead, it applies to project
members wherever they represent the project. So unless we learn that
the "drupliconissad" account actually was a internals contributor,
it's beyond the scope of the CoC considering it also happened
off-list.

However, as Ferenc indicates, what Phil Sturgeon has been saying on
twitter would be within the scope of the CoC, since he is a member of
the project and is actively discussing the project and its members in
a project-related context.

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 11, 2016, at 11:00, Brandon Savage  wrote:
> 
> On Mon, Jan 11, 2016 at 11:26 AM, Anthony Ferrara 
> wrote:
> 
>> The CoC doesn't try to enforce itself outside
>> of the scope of project members. Instead, it applies to project
>> members wherever they represent the project.
>> 
> 
> So just to be clear, your intent is for the CoC to apply *only* to those
> who actively participate in the project.

To be clear, he doesn't say "actively participate." He says only "project 
members when they represent the project."

If that's to be the case, I don't recall seeing explicit definitions of 
"project member" and "represent". Perhaps I have missed them? They're needed so 
as to limit the scope-of-action to what Anthony states above.


-- 
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: Anonymous voting on wiki

[Stanislav Malyshev]

Hi!

> the anonymous voting was reverted almost instantly, or about the recent CoC
> discussion which was back and forth between having the voters/reporters
> privacy, shielding them from potential backlash or having more transparency
> for the voting results, so I'm curious about what Stas meant as well.

I refer to the time when we had a patch that introduced anonymous votes.

My personal opinion is that *if* we were to get to the point when
substantial number of people are being attacked personally merely for
voting this way or that way, that makes them fearful, it would be
horrible. And we'd have to think really hard how to fix that - starting
maybe for them to find out a trusted individual in the community which
would assemble this information and try to figure out where it is coming
from and how to counter that.

If however it is just some people not wishing to invest in supporting
one side or another, out of concern that it takes too much time and
effort to sustain discussion - this is completely normal. We do want
more contributors, but when it comes to voting, I think we want the
contributors to commit to being serious about their position. There's no
obligation to vote if you prefer not to. But if you do, standing by your
vote is part of it.

This was the idea why we decided to have open vote, as I understand it.
So far I don't think it changed - unless, of course, there would be new
data that changes the picture.

When voting on behavioral matters, however, it is different, since the
pattern of bad conduct is at least alleged by the very nature of the
matter in question. So there the benefits of anonymous vote outweigh the
issues, I think.
-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] PHP 7.1 - Argon2

[Solar Designer]

On Mon, Jan 11, 2016 at 10:04:36AM -0500, Anthony Ferrara wrote:
> To my understanding, the crypt scheme hasn't been formalized. Solar
> Designer, can you confirm?

I think it has been, in the way defined by encoding.c in:

https://github.com/P-H-C/phc-winner-argon2

$ echo password | ./argon2 salt | grep ^Encoded
Encoded: 
$argon2i$m=4096,t=3,p=1$c2FsdA$pDVCkCwe3h2SnqGPAGNoM36WzhyGPAd+bb3BLrxyzWw
$ echo password | ./argon2 salt -d | grep ^Encoded
Encoded: 
$argon2d$m=4096,t=3,p=1$c2FsdA$Js0T8jeqwDeja/AQ+x2o4SUn22MofUW2f88RlMRhQso

I haven't been involved in this closely, though.

Alexander

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

[Brandon Savage]

On Mon, Jan 11, 2016 at 11:26 AM, Anthony Ferrara 
wrote:

> The CoC doesn't try to enforce itself outside
> of the scope of project members. Instead, it applies to project
> members wherever they represent the project.
>

So just to be clear, your intent is for the CoC to apply *only* to those
who actively participate in the project. Individuals who do not participate
in the project would not be subject to the CoC *or* the mediation team, and
complaints to the mediation team would be rejected as out of
scope/jurisdiction?

I think this is an important point to discuss, because it sets
jurisdictional boundaries for the project, but also sets intent for what
we're achieving here.

I think this is also important because things have a tendency to expand. We
need to have an answer if a conference organizer asks us to use our
mediation team to resolve disputes at their conference. Or an open source
project. Etc. I don't think we want to become the community's police
force/judge/jury.

This has been my chief concern all along: what to do about people who are
NOT a part of the project. I think the RFC ought to make that explicit.

Brandon

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

[Ferenc Kovacs]

On Wed, Jan 6, 2016 at 3:30 AM, Bryan Hoffpauir  wrote:

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

hi Bryan,

normal wiki user's can't vote on RFCs, only those having a php.net account.
getting a php.net account requires some prior work, for starters you can
look into our code repos (easiest is to clone from https://github.com/php/
because then you can send pull requests when you have something to offer)
or into the open bugs/feature requests at https://bugs.php.net or simply
subscribe to one of our mailing lists which seems interesting to you and
offer your help: http://php.net/mailing-lists.php
when you have a couple of merged patches under your belt you can request a
php.net account at http://php.net/git-php.php

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

Re: [PHP-DEV] Re: Anonymous voting on wiki

[Eli]

Thanks for all the backstory Ferenc, but I knew about the reasons for
this pull request.   It's relation to the current CoC discussion, as
well as the past cases of having anonymous votes and it's rollback.

But my statement was in the context of the thread between Stas &
Andrea.   Wherein Stas stated that we'd talked about having anonymous
voting and we all decided not to do it, and asked if anything had
changed.   Andrea stated that no, things probably hadn't.

My point was:  Given that, as far as I can remember, all those
discussions of anonymous voting happened before the STH votes.  We do
have 'new information' and things that have changed.  Because various
issues were exposed during that voting process, wherein hidden votes
could have helped some people from being beleaguered by people who
disagreed with them, and it would have stopped the ability for people to
be influenced/petitioned/pressed by others to change their vote.

Hence:  I think that there has been something that changed, a new data
point, and therefore a discussion may be merited.

Eli


On 1/11/16 9:51 AM, Ferenc Kovacs wrote:
> On Mon, Jan 11, 2016 at 3:25 PM, Eli  > wrote:
>
> On 1/9/16 5:03 PM, Andrea Faulds wrote:
> > Hi Stas,
> >
> > Stanislav Malyshev wrote:
> >> Hi!
> >>
> >>> This seems useful. I do wonder whether we should use by
> default for
> >>> RFCs. It's interesting to see how different people vote, and
> knowing
> >>> who
> >>
> >> I think we talked about it, and decided not to do it. Anything
> changed?
> >
> > Actually, I don't think so. My fear was probably unfounded.
>
> Has this discussion happened since the STH votes happened?  I know
> it's
> been discussed before, but it seems that the STH vote kinda
> brought this
> out of the woodwork a bit.  And honestly I haven't seen a serious
> discussion about 'by default anonymous' since that time.  (But
> perhaps I
> missed it)
>
> Eli 
>
>
> Not sure which discussion you are referring(probably where were the
> anonymous voting brought up again since the STH votes), but this pull
> request was created because in the Code of Conduct thread somebody
> mentioned that having anonymous votes can be useful when dealing with
> code of conduct sanctions:
> https://www.mail-archive.com/internals@lists.php.net/msg82537.html
> where it was mentioned that previously we had hidden votes for a short
> while but people complained and we reverted it:
> https://www.mail-archive.com/internals@lists.php.net/msg82549.html
> so Stas replied that he will be looking into porting the old patch:
> https://www.mail-archive.com/internals@lists.php.net/msg82651.html
> and here we are now, afaik the current PR from Stas introduces the
> anonymous votes as an optional vote type which is less
> intrusive/controversial than the last one, so we could merge it
> without having any visible effects.
> personally I wouldn't merge until we decided if we need/want the anon
> votes, be that for regular RFCs (in which case I would only support
> the inclusion if closing the vote makes visible who voted what) or for
> some other new type of voting.
>
> -- 
> Ferenc Kovács
> @Tyr43l - http://tyrael.hu

-- 
|   Eli White   |   http://eliw.com/   |   Twitter: EliW   |



signature.asc
Description: OpenPGP digital signature

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

[Anthony Ferrara]

Brandon,

On Mon, Jan 11, 2016 at 8:47 AM, Brandon Savage
 wrote:
>>
>> At the same time, though, if someone is being maliciously hostile what
>> great cover!  A private email is not a PHP-Group managed resource, so no
>> rules!  Twitter, ha, no rules!  Reddit?  LOL like they enforce anything.
>> If someone wanted to send a death threat to another developer about PHP
>> business, I would hope that, as a developer, they are at least smart enough
>> then to do so using a chat program that is "out of scope" so that they're
>> untouchable.  (If they tried to send someone a death threat on list, we
>> should ban them for stupidity. :-) )
>>
>> That's why the scope needs to cover "involves PHP business, regardless of
>> medium" rather than "just on certain pieces of server infrastructure".
>> It's trivial to circumvent otherwise.  Now, how do we define "involves PHP
>> business" in a way that, for example, forbids someone from harassing a gay
>> person about PHP business but doesn't penalize someone for participating in
>> an anti-gay-marriage protest in their home town?  That's the question we
>> should be discussing: How that balance works to minimize that risk, and
>> avoid it being abused to Eich someone.  (Yes, I just used Eich's name as a
>> verb.)
>> 
>>
>>
> Larry,
>
> This is a great point, and brings up an interesting potential compromise
> that might work well for solving this issue.
>
> If the issue is that someone might take an on-list discussion and harass
> someone off-list, why not limit the jurisdiction to individuals who have
> participated on-list in discussion or voted on the issue?

Honestly, this feels like an overly broad hole. It would be easy for
someone to harass off-list, and then just claim "well, I haven't been
part of the discussion for X, so doesn't count". Plus harassment isn't
limited to just discussion on a certain topic.

> And that to me is the crux of the issue. When it comes to making
> discussions on internals more civilized, governing a person's conduct *as
> it relates to their participation in the discussion* is about as far as PHP
> should go. A person who is not a party to the discussion, who does not
> vote, but does have karma, who happens to tweet "I think X is a moron for
> proposing Y" is entitled to that opinion, *until they bring it here.*

While everyone is entitled to their opinion, sharing that opinion is
potentially another story. I think the exact quote you bring here is
one of the things a CoC is designed to prevent. I would absolutely
consider it bad if one karma-holding individual calls another a
"moron" at all in public for proposing an RFC. While we may disagree
with someone, we should hold ourselves to a constructive standard. The
vast majority of people here want to see PHP (as a project) improve.
Even if we don't agree with how someone approaches that, we should at
least hold ourselves to a level of mutual respect. Going out and
calling someone a moron in public is not constructive nor respectful,
and IMHO we as a project shouldn't sit back and blindly say "whatever"
if it happens.

Anthony

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

Re: [PHP-DEV] Re: Anonymous voting on wiki

[Ferenc Kovacs]

On Mon, Jan 11, 2016 at 4:16 PM, Eli  wrote:

> Thanks for all the backstory Ferenc, but I knew about the reasons for this
> pull request.   It's relation to the current CoC discussion, as well as the
> past cases of having anonymous votes and it's rollback.
>
> But my statement was in the context of the thread between Stas & Andrea.
> Wherein Stas stated that we'd talked about having anonymous voting and we
> all decided not to do it, and asked if anything had changed.   Andrea
> stated that no, things probably hadn't.
>
> My point was:  Given that, as far as I can remember, all those discussions
> of anonymous voting happened before the STH votes.  We do have 'new
> information' and things that have changed.  Because various issues were
> exposed during that voting process, wherein hidden votes could have helped
> some people from being beleaguered by people who disagreed with them, and
> it would have stopped the ability for people to be
> influenced/petitioned/pressed by others to change their vote.
>
> Hence:  I think that there has been something that changed, a new data
> point, and therefore a discussion may be merited.
>
> Eli
>
>
ok, I wasn't sure about if they were referring to the old discussion where
the anonymous voting was reverted almost instantly, or about the recent CoC
discussion which was back and forth between having the voters/reporters
privacy, shielding them from potential backlash or having more transparency
for the voting results, so I'm curious about what Stas meant as well.

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

[PHP-DEV] UGLY Benchmark Results for PHP Master 2016-01-11

[lp_benchmark_robot]

Results for project PHP master, build date 2016-01-11 06:30:31+02:00
commit: e6ed53e
previous commit:bb357e0
revision date:  2016-01-08 17:21:59+00: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.09% -0.05%  0.15%  
  7.21%
:-|   Drupal 7.36 cgi -T1  0.22% -0.17% -0.36%  
  4.58%
:-)   MediaWiki 1.23.9 cgi -T5000  0.09%  1.02%  1.40%  
  2.83%
:-)   bench.php cgi -T100  0.02%  2.54%  1.34%  
  4.55%
:-(  micro_bench.php cgi -T10  0.06% -1.29% -0.38%  
  4.86%
:-)  mandelbrot.php cgi -T100  0.01%  3.32%-10.91%  
 -1.36%
---
* Relative Standard Deviation (Standard Deviation/Average)

If this is not displayed properly please visit our results page here: 
http://languagesperformance.intel.com/ugly-benchmark-results-for-php-master-2016-01-11/

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] Fwd: [PHP Wiki] Your DokuWiki password

[Bryan Hoffpauir]

Ferenc,

Thank you for the breakdown, I appreciate the explanation of the process!
I'll get to work :)

Sincerely,

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

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

On Mon, Jan 11, 2016 at 8:42 AM, Ferenc Kovacs  wrote:

>
>
> On Wed, Jan 6, 2016 at 3:30 AM, Bryan Hoffpauir 
> wrote:
>
>> 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/
>>
>
> hi Bryan,
>
> normal wiki user's can't vote on RFCs, only those having a php.net
> account.
> getting a php.net account requires some prior work, for starters you can
> look into our code repos (easiest is to clone from https://github.com/php/
> because then you can send pull requests when you have something to offer)
> or into the open bugs/feature requests at https://bugs.php.net or simply
> subscribe to one of our mailing lists which seems interesting to you and
> offer your help: http://php.net/mailing-lists.php
> when you have a couple of merged patches under your belt you can request a
> php.net account at http://php.net/git-php.php
>
> --
> Ferenc Kovács
> @Tyr43l - http://tyrael.hu
>

Re: [PHP-DEV] Re: Anonymous voting on wiki

[Eli]

On 1/10/16 8:15 AM, Dennis Birkholz wrote:
> I would really like to understand the rational behind anonymous voting
> in the PHP internals context. Votes for RFCs should be purely based on
> technical reasons and whether the language change would benefit the
> language in the long run or not. I see no reason why such a vote
> should be confidential.

I will chime in my quick thoughts here Dennis, as to a reason I could
see for doing so ...  (Not going to argue if 'this reason is good
enough' or not.  But it is a valid reason)

> If a person does not stand behind his/her opinion for a technical
> change, I am not sure if that person should be allowed to decide the
> future of the language. 

So the reason is not because someone isn't willing to 'stand behind
their opinion'.  It's purely about being harassed (perhaps beleaguered
is a better terminology to not confuse this with 'illegal harassment')
for having said opinion.  I was one of the people who, due to my vote on
STH, immediately started being beleaguered for holding my views and for
voting as much.  My inbox/twitter/IRC/etc filled with how I was ruining
PHP and ruining people's lives.  Old friendships were threatened to be
ended.  And my entire week ended up becoming full of responding to these.

Instead of getting to be an informed voter, go in and cast my vote, and
await for the results to be displayed ... I become embroiled into the
arguments, back-n-forth, defense, and dealing with the beleaguering
comments.

Yes, I stood behind my opinion.   But it has made me gun shy about
voting in the future on any contentious topic, because I know I need to
set aside the time to 'deal with that'.  Yet those contentious topics,
are the ones where we should be encouraging as many people as possible
to vote, to make sure that we have a broad spectrum of views and that it
is the 'will of the community' as it were.   And (at least in the US) is
against the idea in general of voter confidence.  Where you are free to
hold your belief without needing to be slammed for it publicly.

So anyway, that's one reason.  Whether it's a good reason or not is up
to others to decide.

> ... But it may be preferable to hide the Person<->Vote table until the
> vote is over. That would provide protection against harassment to win
> someone over and change his/her vote. 

Unfortunately that won't stop the above situation.  While it would stop
the idea of campaigning someone to change their vote (which is perhaps
another reason to do it).  It just means all the above issues would be
taking place post-vote, instead of during-vote.

Eli

-- 
|   Eli White   |   http://eliw.com/   |   Twitter: EliW   |




signature.asc
Description: OpenPGP digital signature

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

[Kevin Smith]

> On Jan 11, 2016, at 9:11 AM, Anthony Ferrara  wrote:
> 
> Brandon,
> 
> On Mon, Jan 11, 2016 at 8:47 AM, Brandon Savage
> > wrote:
> 
>> And that to me is the crux of the issue. When it comes to making
>> discussions on internals more civilized, governing a person's conduct *as
>> it relates to their participation in the discussion* is about as far as PHP
>> should go. A person who is not a party to the discussion, who does not
>> vote, but does have karma, who happens to tweet "I think X is a moron for
>> proposing Y" is entitled to that opinion, *until they bring it here.*
> 
> While everyone is entitled to their opinion, sharing that opinion is
> potentially another story. I think the exact quote you bring here is
> one of the things a CoC is designed to prevent. I would absolutely
> consider it bad if one karma-holding individual calls another a
> "moron" at all in public for proposing an RFC. While we may disagree
> with someone, we should hold ourselves to a constructive standard. The
> vast majority of people here want to see PHP (as a project) improve.
> Even if we don't agree with how someone approaches that, we should at
> least hold ourselves to a level of mutual respect. Going out and
> calling someone a moron in public is not constructive nor respectful,
> and IMHO we as a project shouldn't sit back and blindly say "whatever"
> if it happens.


Ok, so given this continued line of reasoning, is this a fair summary: 

The goal of this proposal is to create a code and enforcement body that seeks 
to improve the content and tone of communications by and between members of the 
PHP community regardless of venue using punitive measures if necessary.


Kevin Smith
Hearsay Interactive 

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

[Stanislav Malyshev]

Hi!

> least hold ourselves to a level of mutual respect. Going out and
> calling someone a moron in public is not constructive nor respectful,
> and IMHO we as a project shouldn't sit back and blindly say "whatever"
> if it happens.

OK, so what should we do instead? So far my calls to apply some TDD were
not heard, maybe this time?

Let's consider an example of twitter user drupliconissad. It may be
genuine individual or a troll, it doesn't matter either way.
If you read the feed, you can find much more than "moron". Now, had we
had CoC, what would we do? We don't know who that is, so private
moderation is out of the question, even if we did - it's not look like a
personal conflict that can be amicably reconciled. Should we issue a
proclamation saying "we think some anonymous account on twitter is being
bad"? Should we ban that person (or group of persons - we have no idea
either way), which we have no idea who that is, from our list? Any other
ideas?
-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] PHP 7.1 - Argon2

[Anthony Ferrara]

+ Solar Designer

On Mon, Jan 11, 2016 at 7:55 AM, Rouven Weßling  wrote:
>
>> On 11 Jan 2016, at 13:27, Pierre Joye  wrote:
>>
>> Hi,
>> On Jan 11, 2016 4:12 PM, "Rouven Weßling"  wrote:
>> >
>> > * Is there already a crypt scheme for Argon2? Or are there any efforts to 
>> > define one? It would good if PHP wouldn’t be an island.
>>
>> https://github.com/P-H-C/phc-winner-argon2
>>
>> The reference implementation. If anything we should use it.
>>
>> I am not sure if we should bundle the library tho'.
>>
> Thanks for the link. The included example seem to use $argon2i$ and $argon2d$ 
> as crypt scheme. A cursory search didn’t show anyone else using Argon2 with a 
> crypt scheme, so this would probably be good enough.

To my understanding, the crypt scheme hasn't been formalized. Solar
Designer, can you confirm?

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 11, 2016 8:47 PM, "Brandon Savage"  wrote:
>
> >
> > At the same time, though, if someone is being maliciously hostile what
> > great cover!  A private email is not a PHP-Group managed resource, so no
> > rules!  Twitter, ha, no rules!  Reddit?  LOL like they enforce anything.
> > If someone wanted to send a death threat to another developer about PHP
> > business, I would hope that, as a developer, they are at least smart
enough
> > then to do so using a chat program that is "out of scope" so that
they're
> > untouchable.  (If they tried to send someone a death threat on list, we
> > should ban them for stupidity. :-) )
> >
> > That's why the scope needs to cover "involves PHP business, regardless
of
> > medium" rather than "just on certain pieces of server infrastructure".
> > It's trivial to circumvent otherwise.  Now, how do we define "involves
PHP
> > business" in a way that, for example, forbids someone from harassing a
gay
> > person about PHP business but doesn't penalize someone for
participating in
> > an anti-gay-marriage protest in their home town?  That's the question we
> > should be discussing: How that balance works to minimize that risk, and
> > avoid it being abused to Eich someone.  (Yes, I just used Eich's name
as a
> > verb.)
> > 
> >
> >
> Larry,
>
> This is a great point, and brings up an interesting potential compromise
> that might work well for solving this issue.
>
> If the issue is that someone might take an on-list discussion and harass
> someone off-list, why not limit the jurisdiction to individuals who have
> participated on-list in discussion or voted on the issue?
>
> For example, during the very heated discussion over static type hints, if
> someone who had discussed the issue on Internals had then gone out to
> Reddit and called Zeev a bunch of terrible things, that could be made
> actionable under this code of conduct, reportable to the mediation team.
>
> On the other hand, we have a lot of people with karma who don't always
vote
> and may not participate in a particular issue on-list. If two people who
> have karma have a run-in outside the discussion of an issue related to
PHP,
> they should have to be adults and hash that out themselves.
>
> And that to me is the crux of the issue. When it comes to making
> discussions on internals more civilized, governing a person's conduct *as
> it relates to their participation in the discussion* is about as far as
PHP
> should go. A person who is not a party to the discussion, who does not
> vote, but does have karma, who happens to tweet "I think X is a moron for
> proposing Y" is entitled to that opinion, *until they bring it here.*
>
> If, on the other hand, the goal of the CoC is not to make Internals a
> better place, but to govern what people in the community think, say and do
> when they have no direct involvement with this group, that's another
matter
> entirely. And a much scarier one at that, don't you think?

My main concerns or worries are exactly those.

I fail to understand how one can think that the CoC could be about
censorship  (which is basically what this comment says).

I also fail to understand how one can fail to accept that we already had
and have issues, despite numerous people having experienced it.

I remember a time where we use to say "if you cannot stand the heat, leave
the kitchen" and I was actually supporting this idea. The problem is is
that it went too far. And we have to admit our weakness first to be able to
create a somehow useful CoC. If we do not see us having problems, there is
no point to even discuss a document to solve non existant (for us) problems.

As a side but important note, it is very disturbing to read so many of us
denying the very issues we have. Even if it is denied in a very diplomatic
way. I am convinced that this is the first problem we must solve to get a
CoC, to accept the very existence of these problems.

My apologizes if this is seen as arguing but I feel like it is the only
fundamental difference I can see between the two camps.

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

[Chase Peeler]

On Mon, Jan 11, 2016 at 12:52 PM Pierre Joye  wrote:

> On Jan 11, 2016 8:47 PM, "Brandon Savage" 
> wrote:
> >
> > >
> > > At the same time, though, if someone is being maliciously hostile what
> > > great cover!  A private email is not a PHP-Group managed resource, so
> no
> > > rules!  Twitter, ha, no rules!  Reddit?  LOL like they enforce
> anything.
> > > If someone wanted to send a death threat to another developer about PHP
> > > business, I would hope that, as a developer, they are at least smart
> enough
> > > then to do so using a chat program that is "out of scope" so that
> they're
> > > untouchable.  (If they tried to send someone a death threat on list, we
> > > should ban them for stupidity. :-) )
> > >
> > > That's why the scope needs to cover "involves PHP business, regardless
> of
> > > medium" rather than "just on certain pieces of server infrastructure".
> > > It's trivial to circumvent otherwise.  Now, how do we define "involves
> PHP
> > > business" in a way that, for example, forbids someone from harassing a
> gay
> > > person about PHP business but doesn't penalize someone for
> participating in
> > > an anti-gay-marriage protest in their home town?  That's the question
> we
> > > should be discussing: How that balance works to minimize that risk, and
> > > avoid it being abused to Eich someone.  (Yes, I just used Eich's name
> as a
> > > verb.)
> > > 
> > >
> > >
> > Larry,
> >
> > This is a great point, and brings up an interesting potential compromise
> > that might work well for solving this issue.
> >
> > If the issue is that someone might take an on-list discussion and harass
> > someone off-list, why not limit the jurisdiction to individuals who have
> > participated on-list in discussion or voted on the issue?
> >
> > For example, during the very heated discussion over static type hints, if
> > someone who had discussed the issue on Internals had then gone out to
> > Reddit and called Zeev a bunch of terrible things, that could be made
> > actionable under this code of conduct, reportable to the mediation team.
> >
> > On the other hand, we have a lot of people with karma who don't always
> vote
> > and may not participate in a particular issue on-list. If two people who
> > have karma have a run-in outside the discussion of an issue related to
> PHP,
> > they should have to be adults and hash that out themselves.
> >
> > And that to me is the crux of the issue. When it comes to making
> > discussions on internals more civilized, governing a person's conduct *as
> > it relates to their participation in the discussion* is about as far as
> PHP
> > should go. A person who is not a party to the discussion, who does not
> > vote, but does have karma, who happens to tweet "I think X is a moron for
> > proposing Y" is entitled to that opinion, *until they bring it here.*
> >
> > If, on the other hand, the goal of the CoC is not to make Internals a
> > better place, but to govern what people in the community think, say and
> do
> > when they have no direct involvement with this group, that's another
> matter
> > entirely. And a much scarier one at that, don't you think?
>
> My main concerns or worries are exactly those.
>
> I fail to understand how one can think that the CoC could be about
> censorship  (which is basically what this comment says).
>
> The argument isn't that people are trying to censor the list. The argument
is that such a policy will inherently lead to such actions, no matter how
good the intentions might have been.


> I also fail to understand how one can fail to accept that we already had
> and have issues, despite numerous people having experienced it.
>
> I, for one, have never denied they exist. My point has been even if they
do exist, this isn't the proper means of addressing them.


> I remember a time where we use to say "if you cannot stand the heat, leave
> the kitchen" and I was actually supporting this idea. The problem is is
> that it went too far. And we have to admit our weakness first to be able to
> create a somehow useful CoC. If we do not see us having problems, there is
> no point to even discuss a document to solve non existant (for us)
> problems.
>
> Again, whether problems exist or not is not relevant in my view. Whether
or not the approach will solve such problems if they do exist, is what I
care about. Even if they will, I also care about exploring what the
unintended side effects may be.


> As a side but important note, it is very disturbing to read so many of us
> denying the very issues we have. Even if it is denied in a very diplomatic
> way. I am convinced that this is the first problem we must solve to get a
> CoC, to accept the very existence of these problems.
>
> Again, not denying their existence. I also haven't seen that many people
that have denied their existence either. I've seen a few people asking for
examples, and others stating that we 

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

[Stanislav Malyshev]

Hi!

> I fail to understand how one can think that the CoC could be about
> censorship  (which is basically what this comment says).

I can explain you that very easily: there are known instances where CoCs
were used and even more instances where there were attempts to use CoCs
and CoC-like structures exactly for that. It's not a concern because
people think it *might* happen, it's a concern because it *already
happened* elsewhere and people think it also might happen *here*.

> I also fail to understand how one can fail to accept that we already had
> and have issues, despite numerous people having experienced it.

That's because nobody does that. Instead, the question is whether the
specific proposal is helpful to fix specific issues. The conversation
goes like this:

A: here's solution X!
B: for what?
A: for problem Y
B: but do we have problem Y? Also, X does not seem to solve Y and also
introduces problem Z
A: we can solve Z easily! Also, here's proof problem Q exists.
B: but Q is not Y. And we didn't see Y exists so far. And your solution
to Z sounds iffy.
A: why you keep denying problem Q exists?!

> create a somehow useful CoC. If we do not see us having problems, there is
> no point to even discuss a document to solve non existant (for us) problems.

As I note again, talking about abstract "having problems" as an argument
to do a specific thing is not very useful.

> As a side but important note, it is very disturbing to read so many of us
> denying the very issues we have. Even if it is denied in a very diplomatic
> way. I am convinced that this is the first problem we must solve to get a
> CoC, to accept the very existence of these problems.

First of all, asking for proof and denying is different thing (though
people often confuse the two, but these *are* different). Second, "very
issues we have" is, again, very unspecific thing, so it's not even
possible to deny it. Before I could even deny that "these problems
exist" - or before you claim I or anybody else does - I'd like to know
what exactly are "these problems" in specific terms. Because some of the
problems were almost unanimously recognized, some was not, so it's not
clear what parts we are talking about.
-- 
Stas Malyshev
smalys...@gmail.com

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