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

[Stanislav Malyshev]

Hi!

> [http://archive.is/1A8SQ], wherein she suggested that you ignore the

And this is exactly what we want to prevent from happening here.

-- 
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] [Re-proposed] Adopt Code of Conduct

[Zeev Suraski]

> I wouldn't say the idea of a code of conduct is really a constitution per se 
> (it's
> not setting down the foundation and goals of the PHP project, merely rules
> for misconduct)

Should somehow this RFC get ratified, it would be by far the closest thing that 
the PHP project will have for a constitution. 
For what it's worth, I find the description 'rules for misconduct' extremely 
telling and fairly horrible way to describe a Code of Conduct, as I'm sure any 
people involved with education would agree.

> That being said,
> you may have a point with it not being what RFCs were really intended for.

Thanks for acknowledging the possibility - however remote - that the author of 
the RFC process he 'may have a point' about what the document he was the lead 
author for was or rather wasn't about :)

> But we don't really have an alternative process for this currently 
> established,
> so an RFC is the best we can do.

Oh, but we do.  As I'm sure many of us remember, PHP existed for 15 years 
before the RFC process, and it actually became the most popular language on the 
planet during that time.  Yes, the RFC process made things go quicker and 
evolution faster - but given it was designed for technical decisions and 
administrative items - not constitutional ones - it cannot be used here.

Namely - decision by consensus.  This is absolutely required in a topic as 
far-reaching as this, which is very clearly outside the scope of the RFC 
process.

> RFC revival is essentially like forking, and that's always allowed in open-
> source.

We have clear rules which disallow revival of RFCs which failed a vote for a 
duration of six months, unless they're very substantially modified, so revival 
isn't always allowed in open source.

Maybe I'm a cynic, but when I saw that the RFC was withdrawn, I was (almost) 
literally counting the minutes before someone came, in the electronic 
equivalent of a shining armor, to revive it.  It's also clear that had Derick 
not done it, someone else would have.
Maybe I'm a cynic #2, but to me, it's an attempt to make a point in an undue 
manner.  And I don't think that should be allowed.  I think we all have bigger 
fish to fry right now though, so that's not something I'm going to actively 
argue on - especially as the current Voting RFC doesn't detail that.  I'm 
merely stating my opinion.

> > Third, on undue pressure.
> > Certain people have either implied or outright said that not having a CoC
> will make them reconsider actively contributing to PHP.  This is undue
> pressure IMHO, avoiding the use of bigger words.
> 
> It might leave others feeling pressured

s/might/absolutely does.

>, but it's not their fault if those
> contributors feel unsafe without a code of conduct.

I'll state right here that I find it virtually impossible to believe that the 
abovementioned individuals feel *unsafe* because of the lack of a CoC.  And 
before I'm under a torrent of attacks that I couldn't possibly *know* how 
people feel - I'm acknowledging that right now.  I don't.  But that's what I 
think, and I stand behind this guesstimate.

> Nor is the flip-side true: a
> certain person said they fear getting in trouble for their political views if 
> the
> CoC passes, and if they wanted to leave as a result, so be it.

But incidentally, nobody did - at least to the best of my knowledge - even 
though I wouldn't be surprised if some do.  Which is precisely the difference 
between what can be described as a threat, and a true action->consequence.

> Nobody is under
> any obligation to contribute to PHP, they can freely choose not to contribute
> if they wish, and that is their right.

Right.  But I'll say it again - I think that threatening to quit the project if 
one doesn't get their way about something - anything - is undue pressure.  
That's my opinion, and I'm not pretending it's the law so obviously people are 
free to ignore it.

> I think it would be worse if you were not allowed to make such statements.
> It's better that people be aware of consequences than be surprised later.

I think it would be awful if people weren't *allowed* to make such statements.  
And at the same time, it's disappointing to me that people *choose* to make 
those statements.
So far, the only document around that is trying to claim jurisdiction about 
what people *may* or *may not* say is the CoC RFC (notice the fundamental 
difference between 'may', 'should' and 'encouraged to').

> Personally, I don't see how expanding from covering serious misbehaviour
> (harassment etc.) to covering more generally non-conducive-to-civil-
> discussion actions would make things more or less open to potential abuse.
> Generally, opinions are not the problem, but rather the way people go about
> expressing them.

If I understand you correctly, you're saying that assuming we have a penalty - 
at the discretion of a given body - to temp-ban someone from the project and 
recommend a perma-ban, it doesn't matter whether they 

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

[Zeev Suraski]

> -Original Message-
> From: Pádraic Brady [mailto:padraic.br...@gmail.com]
> Sent: Thursday, January 21, 2016 1:43 AM
> To: Zeev Suraski 
> Cc: Derick Rethans ; PHP Developers Mailing List
> 
> Subject: Re: [PHP-DEV] [RFC] [Re-proposed] Adopt Code of Conduct
> 
> Hi,
> 
> Up front, I agree the objective of the COC needs to be clearly stated.
> There is confusion, whether it's here or externally by observers, as to
> whether this is intended to fix mailing list toxicity (I assume, for now, 
> not) or
> intended to state the projects intentions should there be a complaint
> concerning conduct as specifically listed in the COC text per the RFC. It 
> serves
> neither side when this confusion gets muddled into argument for, against or
> in-between.

I think the fact that this RFC was (and still is) perceived to be a solution 
for the toxic internals problem -  actually served the proponents of this RFC 
very well.  On one hand, this is what people at large care about.  On the other 
- the proponents can tell the those who oppose that it's not at all what the 
RFC is about, and that their worries about this becoming a tool for a 
behavioral/thought police are completely baseless.

Note that despite the fact that Derick - who's now the RFC author - clearly 
said that the reason he's reviving the RFC is because internals is toxic - 
you're still assuming that the RFC isn't intended to 'fix mailing list 
toxicity'.

Can we get any more confused than that?

> At a basic level, what exactly is a code of conduct where the only
> consequence is mediation, where both parties are assumed to have good
> will, and where the outcome is ??.

My take?  A successful one.  One that we can all rally behind, as opposed to a 
controversial one that is creating much angst.  Please see my response to 
Andrea.

> That's the a problem from my
> perspective. What is the outcome? Does mediation continue indefinitely
> without results?

No, in the vast majority -  and I do mean VAST majority, mediation works and 
results would be quick.  When people are told that they should cool off, they 
typically do.  I know I would.  Even more so if that mediation team could point 
me to a certain desired behavior I'm not quite following at that time, and do 
so respectfully and not judgmentally. 

> While the mediation is ongoing for the long haul, will be
> there be any remediation set to protect a theoretical victim? What is Plan B?

I don't think we can go on discussing two completely different issues - safety 
and 'toxicity', while jumping in between them as if they're the same thing.  
The way the current RFC author sets of the scope is much wider than safety 
issues, and the use of the word 'victim' and 'remediation' are not really 
relevant to it - at least in the vast majority of incidents we're likely to 
experience

> Part of the COC is to explicitly limit ad-hoc reactions should things go
> completely down the gutter by defining something upfront. By extension,
> any uncertainty of what would happen should Person A complain may act as
> a deterrent to making such a complaint. It could be anticipated that long
> drawn out procedures with an unknown ending are in and of themselves
> stressful (and to both parties to boot).

There's just no way to undo the damage that the threat of penalties does when 
the goal is trying to foster positive behavior.  Any education person - and 
hopefully most parents - will tell you that.  Our brains respond completely 
differently to demands and threats versus encouragement and guidance.

There's no absolute winning formula, and there's no one size fits all.  Yes, in 
an extreme, uncommon case - the fact we're focusing on desired behavior and not 
on 'deterrence' - might cause a certain individual to feel they can do a 
certain something and get away with it (something, that if safety issues was 
what we're dealing with, may very well be illegal and carry criminal 
penalties).  Is it worth to design our whole system around that extremely 
infrequent situation *AT THE EXPENSE* of how we deal with the normal day to day 
situations?  I know my answer. 

Zeev

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

[Pádraic Brady]

Hi,

On 21 January 2016 at 04:37, Kevin Smith  wrote:
> I noticed you were contacted by Randi Lee Harper [https://archive.is/b8RDW], 
> the ironically abusive founder of the Online Abuse Prevention Initiative 
> [https://archive.is/eqco9][http://archive.is/A1Azz] known for attacking and 
> attempting to eject from projects/employment people she associates with 
> groups she doesn’t approve of [http://archive.is/1A8SQ], wherein she 
> suggested that you ignore the Code of Merit that Pavel recommended for 
> consideration because she associates the author of said code with a group 
> that—though entirely unrelated to his Open Source contributions—she finds 
> undesirable and then proceeded to make general derogatory comments about him 
> [again, https://archive.is/b8RDW].

Are you here to debate the proposed COC, or to mount personal attacks
on someone outside of the PHP community?

> (My deepest apologies for such a tremendous run-on sentence.)
>
> I certainly hope this isn’t indicative of the spirit of this proposal. This 
> exchange really seems to suggest the goal of these codes in general, and now 
> possibly this one in particular, is what so many of us have feared: to 
> exclude people with wrong ideas and associations, as defined by the in-group.

Is that what the RFC actually states though? As it's a code of
conduct, it's directed at specific actions not whatever is running
through your, or my, head.

Paddy

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

Re: [PHP-DEV] [RFC] [VOTE] Class Constant Visibility

[Xinchen Hui]

Hey:

On Wed, Jan 20, 2016 at 7:05 PM, Michael Wallner  wrote:

> On 08/12/15 10:56, Dmitry Stogov wrote:
> > Hi Sean,
> >
> > The PR has been merged into master.
> > Please update the RFC accordingly.
> > Thanks to Nikita and Xinchen for code review and suggestions.
> >
>
>
> This patch seems to cause problems for me with registering constants on
> internal interfaces; see bug #71413 https://bugs.php.net/71413

this should be fixed in :
https://github.com/php/php-src/commit/62c1c11ad34103729988df9edea343337a900ba9

thanks

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



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

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

[Stanislav Malyshev]

Hi!

> It might leave others feeling pressured, but it's not their fault if
> those contributors feel unsafe without a code of conduct. Nor is the

I don't want to be dismissive, but I do not see anything on the list
that should make anybody feel *unsafe* (unless of course I misunderstand
what you mean by "unsafe", in which case please correct me).
Uncomfortable - sure, exhausted and exasperated - oh yes, but unsafe?
I mean, everybody has the right to *feel* whatever they like, but I
don't see how we can accept any responsibility for those feelings if
they have no base in anything that actually happened? I feel like more
insight into this would definitely be useful - what concerns about
safety we have and CoC would fix?

> flip-side true: a certain person said they fear getting in trouble for
> their political views if the CoC passes, and if they wanted to leave as
> a result, so be it. Nobody is under any obligation to contribute to PHP,
> they can freely choose not to contribute if they wish, and that is their
> right.

That is certainly true, in general. In particular, though, the argument
"do as I tell, or I'll take my toys and leave" is not a very
constructive approach, because it leaves no space for seeking compromise
- either you do exactly as you told to, fully submitting to whatever the
other person says to do, or no collaboration happens ever. While on some
(very small set of) questions it may be the way to go, in most areas I
don't think this is a fair way to do things.

> I think it would be worse if you were not allowed to make such
> statements. It's better that people be aware of consequences than be
> surprised later.

I am a firm believer in freedom of expression, so "allowed" is not a
question, however some arguments definitely sound very manipulative, and
"do this, or I leave" is one of them. So it would be nice to avoid it if
at all possible. Especially when it comes to respected members of the
community whose contribution is valued - it is too easy to abuse that as
a means of just silencing anybody who disagrees.

> Personally, I don't see how expanding from covering serious misbehavior
> (harassment etc.) to covering more generally
> non-conducive-to-civil-discussion actions would make things more or less

Very easily. Instead of discussing things on merits, people start
rule-laywering and offense-sniping each other. In fact, we see this
happening from time to time even now, when people who dislike RFC try to
argue against it on technicalities, and I think it does not improve
matters, but if we officially enshrine this as a policy, this would grow
tenfold. It is much easier to say "she is posting too often!" or "he
disagrees with me too much and I feel offended and threatened!" and try
to shut the opponent up than to address the matter of disagreement. So
we are creating motivation for destructive behavior. This needs to be
addressed.

> Even if you believe that it's not a problem, that doesn't change the
> opinion of people who do think that an unenforced code of conduct is
> problematic.

Worse than not having any at all? If so, why exactly - what aspect or
behavior specifically is becoming worse?

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

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

[PHP-DEV] PHP 7.0.3 RC1 is available for testing

[Anatol Belski]

Hi,

PHP 7.0.3 RC1 was just released and can be downloaded from:

https://downloads.php.net/~ab/

The Windows binaries are available at

http://windows.php.net/qa/

This release contains a number of bugfixes.
For the list of bugfixes that you can target in your testing, please refer
to the NEWS file:

https://github.com/php/php-src/blob/php-7.0.3RC1/NEWS

Please test it carefully, and report any bugs in the bug system.

The stable release is planned for February 4th, if no critical issues will
be discovered in the RC.


Below is the verification information for the downloads:

php-7.0.3RC1.tar.bz2
SHA256 hash:
7452f38e32288f9fcd18b4c385df76a13d9ac790f38d7e07ee4b5d3944bb9158
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJWn1AWAAoJELyqMOqcDVdjSn4H/05Kz9NQwL4t8Sv3xIsJmmsw
I0bmjP2S0L3MS+9nUWc+mhhtuVaHAJ8NI/wevKM0MKR+VcOxz8jVVQoO0Yehs0Wh
26jhNnKo1cXk31vq1alz5rdXoh8cvERsN0R7e4q3q4zTKmC7iRTa7tNOHWyI3NqL
xNu51lulBE5PzBBBeOifM7TwTLIZieyhOrkBMwKeSKFNrLdFJYx4I9twppA3eeSe
Kh//t0UH35QrFYsK86vhDN0KASDeqOUVxknAf34OdPRzfvNWSYM0vyOfuiE900qe
PHzdoKjL12gdl6NRCgKDgjySIFc1dWtKoh03HSx9mtlPVtXOzFXU/0/tIk4XcoM=
=h+FT
-END PGP SIGNATURE-


php-7.0.3RC1.tar.gz
SHA256 hash:
7af732c88d1f4a63694d3d616aa92b0d6fb23cb5e7a4bf1e3a934d96f1c2580a
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJWn1AZAAoJELyqMOqcDVdjT4AH/0Wqg7WYgI4tBTh3NQh6f0qI
ZkmtaF6zqMp1uqLOR2y1oIF20ZC3rpkDDsPFssazpenSgbFcHPC1BPadDGPVFd6p
3w9Jg/MLH0qbBhqMfnITx8WIHIc5HGC8GiElt9vQWfplRTN0Fvgty5fpEKMet+SK
AutD6hXMrDWFb9KGE0e3vNP4M023vm6CRKklztZU30WTcgcGDsdeOsPppG0aPKJM
OEvHjOu/tQavAVyoO4tyS48/Sfekml6BjEpiym/7b7jPFYm5XfbS2zosKSKgl2Jg
KbIT1IeLJKGxmkAzc9JzYGesOMUei/dENnBdo4u0tUaa6f0va/Cnlyx7RPvKEJs=
=XAGe
-END PGP SIGNATURE-


php-7.0.3RC1.tar.xz
SHA256 hash:
fbf475497d31d8a189ec1b61fe11912802e877476c74f072e8660322bf09e294
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJWn1AbAAoJELyqMOqcDVdjagUH/0MhyDF42yDOKf5rB97Lj/V2
3PCusKIPJfb3AXijbYErH7OqktgsnyOmh+z3qkIHiejPLUGhSYryOgCPsIwkjG7O
llFRDB9ExjQjq/MZOhhoTPvlrkPsW5pawIbUBYjNz6BY04xlE3hWezxBAp4iwyz+
yYyfGSCwtLAOL75ZhsHgCvNI5hvH+268W/7S1xhKaFyt3sSgFAiyBcF9J0MhxTbq
8kBWkl8DpUje19lQbLGEv9KkJQHC/OA+nLXK4BT1D9OfDCRMlJghcQyEGFyy79/0
flfLVLXv9mXuyZXDZUbS6iMmCZ5ceAMg4g+QKl5MtsXHcSv6EhaPEo14qWfYNcc=
=UsDH
-END PGP SIGNATURE-

Thank you for your support.

Anatol Belski and Ferenc Kovacs


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

Re: [PHP-DEV] [RFC] Allow specifying keys in list()

[Stanislav Malyshev]

Hi!

> Here's an RFC that would extend the syntax of list() to be more useful
> with associative arrays:
> 
> https://wiki.php.net/rfc/list_keys
> 
> Please read it and tell me your thoughts.

After reading the RFC, it looks like a great idea. I wouldn't exactly
encourage this for replacement of named parameters (for one, I
understand it would produce some complaints - like notice? - if the key
does not exist) but there are cases when it's useful and I don't see any
harm in 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] [Re-proposed] Adopt Code of Conduct

[Derick Rethans]

On Wed, 20 Jan 2016, Stanislav Malyshev wrote:

> Hi!
> 
> > I've decided to re-propose the CoC RFC. There are many reasons for it, 
> > but there are a few points I want to make.
> > 
> > I strongly believe that a Code of Conduct is required. The amount of 
> > toxic behaviour on this list is in my opinion unacceptable. It drives 
> > people away, it certainly did. It is also one of the reasons I am not 
> > nearly as active as I used to be.
> 
> Thanks for continuing the discussion. I'd like however to point out that
> one of the major points of contention, as I see it - that it is not at
> all clear how having CoC prohibiting things like "the use of sexualized
> language" and "trolling", would help with "toxic behavior". I want to be
> very clear, because I feel this concern is not being understood, so I
> will try to outline it as detailed as I can, please excuse the verbosity:
> 
> 1. I do not think literally anybody wants to see trolling or sexual
> language attacks, or harassment, etc. on the list. I think we all agree
> this is unacceptable.
> 
> 2. I think most of the people here know that the list has been not the
> friendliest place ever, and most of the people here would like to
> improve that.
> 
> 3. I do not think we do have now or ever had a significant problem with
> behaviors described by "Code of Conduct Text". I think the problem
> described may be caused by other set of behaviors, not covered by "Code
> of Conduct Text".
> 
> 4. Given that, it is not clear to me, and apparently some other folks
> too, how banning those (as universally agreed) despicable behaviors is
> going to lead to any improvement on the matter of "toxic".
> 
> 5. Since so many people somehow did not understand that, judging by
> their comments, this does not mean anybody thinks it is OK to behave
> that way (see 1). It means that it appears we are trying very hard to
> fix not the same place that is claimed to be broken.
> Now, it can be that *both* places are broken, or that the fix can be
> applied as a preventive measure - and both are fine. But arguing "we
> have problem X therefore let's apply fix for a different problem Y"
> sounds strange to me.
> 
> I think clarifying that matter would help.

I tend to agree with all the above. Adding a code of conduct that (I 
hope!) everybody universally agrees with - whether it's the current 
text, or one of the ones you listed below, or some mash up - is not 
going to fix the toxic and unfriendly behaviour. In my opinion, it should act 
as a general set of moral guidelines.

But at the same time I think it is also important to point out that we 
will actively do things, and provide a process for dealing with 
compliants, if things *do* go wrong. A Code of Conduct (can't bear to 
call to call it CoC, sorry), should show that we are serious about 
having a healty and welcoming project, where we won't tolerate any sort 
of abusive behaviour. I am going to have a chat with the Drupal people 
to see whether we could learn from the process, and that will likely 
result in an updated text of the Contributor Covent.

So on top of that, I am suggesting to accept the Collaborative 
Contributing Guidelines, to address to toxidity of the list, which 
nicely ties in into:

> Also, there was a complaint that there has been too much critique and 
> not enough constructive proposals. I think there is some truth to 
> that, as it is much easier to find bugs than to develop things, and 
> much more people submit bug reports than fix them. This is natural, 
> but this certainly could use improvement. In that spirit, I would like 
> to reiterate the proposal of handling CoC matters that I personally 
> think would be the best. This is my personal approach, so please feel 
> free to amend, criticize and disagree.
> 
> 1. Make a values statement, along the lines of:
> https://www.drupal.org/dcoc
> https://www.djangoproject.com/conduct/
> https://www.freebsd.org/internal/code-of-conduct.html
> https://meta.wikimedia.org/wiki/Grants:Friendly_space_expectations
> 
> This document should emphasize behaviors we want to achieve and
> reinforce, not be just a catalog of behaviors we hate.
> 
> In this document, as one paragraph, include "unacceptable behavior"
> statement from current RFC, verbatim or suitably modified (that of
> course does not preclude including other parts of it in other paragraphs).

You mean the list of "Examples of unacceptable behaviour by participants 
include", right?

> "Constructive Collaboration Guidelines" probably should be part of this
> document too - and be stated before the unacceptable part. I know it
> sound like nitpicking but I think tone of the documents is important and
> if we start with negatives (even by rejecting them) it sets different
> tone than if we start with positive. It's one thing to welcome people to
> your house with "Welcome, friend, feel at home!" and another with
> "Please don't steal my wallet and don't kick my dog!"

I agree, the 

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

[Derick Rethans]

On Thu, 21 Jan 2016, Allan MacGregor wrote:

> Taking a step back, instead taking a knee-jerk reaction; I think Kevin 
> brought up a valid point. Is very clear that there are certain actors 
> that are pushing for a specific version of this code of conduct to use 
> it as a political tool.

I am going to stop you right there. There is no agreement on the text of 
the code of conduct, and rather, perhaps not even on the base which 
might result in PHP's version of anything. Randi merely pointed out her 
specific issues with an alternative Code of Conduct (which, funnily, 
said it is actually not one). As I already wrote, I don't think it's 
suitable: http://news.php.net/php.internals/90771

> This is it what concerns most people regarding this specific CoC; you 
> want to debate the CoC proposed, fine. Personally here are my issues 
> with it:
> 
> - Language is vague and open to interpretation
> - The CoC seems to be more concern with punitive action rather than
>   establishing the values of the community.

Picking up on these two first. Both points are probably valid, and I 
have already asked for constructive feedback on it. Just stating these 
two points is not feedback, it's just saying that you don't like it. 
Suggest how to improve it, and I would be more than happy to listen to 
the feedback. We might not agree though.

> - There is no mechanism or ability for one to confront ones accuser

That is a tricky one. In my opinion, in the case of abuse as pointed out 
in the draft CoC, I think this is fair, and necessary that we all for 
reports of abuse in private, and with secrecy. Without it, an accusor is 
likely immediately going to be lambasted by the perpetrator. 

Having a private mediation board or process is for the same reasons that 
companies allow annonymous feedback about managers, co-workers, peers 
and leadership. Their HR basically would function as our proposed 
Mediation Team. Without privacy, it is extremely unlikely people would 
even bother putting in a complaint, afraid of a public outlash.

However, the accuser can through the Mediation Team of course reach the 
complainant - but the identity should be guarded as private. The current 
language in the RFC reads:

"Reasonable efforts should be taken to ensure the privacy of the
reporting party. The only two exceptions would be if the 
incident was public or if the reporting party agrees to be 
identified."

That is in the context only among the accusor, Mediation Team, and 
accused. Not towards the community as a whole.

cheers,
Derick

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

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

[Pádraic Brady]

Hi,

>For example, http://code-of-merit.org/ seems much more reasonable in
>"getting the things done" than the Covenant.

I reviewed this last night, and it hasn’t fared any better after a
night’s sleep. The Code of Merit essentially creates an armour clad
rejection of any non-technical topic. It makes this very clear by
explicitly stating that such topics must be discussed elsewhere. It
also explicitly states that “disruption of the project will not be
tolerated”. It doesn’t define disruption, of course. It doesn’t even
define a mediation process. I doesn’t actually mention any undesired
interpersonal conduct at all.

It’s effectively the total opposite of the currently proposed RFC, and
then some.

Paddy

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

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

[Allan MacGregor]

The Code of Merit essentially creates an armour clad


rejection of any non-technical topic.

Is really that bad, this is an open source project. We are talking about 
a programming language not a socio-political movement? Or did I missed 
the memo?


When it comes down to PHP itself the main concern should be the language 
and the development of the project.




Pádraic Brady wrote:


The Code of Merit essentially creates an armour clad
rejection of any non-technical topic.
-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Pádraic Brady]

Hi,

On 21 January 2016 at 14:33, Allan MacGregor
 wrote:
> Padraic,
>
> Taking a step back, instead taking a knee-jerk reaction; I think Kevin
> brought up a valid point. Is very clear that there are certain actors that
> are pushing for a specific version of this code of conduct to use it as a
> political tool.

The RFC has actual text, which can be read, examined and discussed.
There is no need whatsoever to drag in anything beyond unless directly
relevant to the text at hand. Personal attacks on people who support a
COC, or do not support a COC, aren't productive. If there is a
political plot to undermine whatever in PHP, then please do support
this by quoting from the RFC.

> This is it what concerns most people regarding this specific CoC; you want
> to debate the CoC proposed, fine. Personally here are my issues with it:
>
> - Language is vague and open to interpretation

Propose specific text which also addresses harassment and the other
not vague words. I’m sure people will happily read and review it.

 > - There is no mechanism or ability for one to confront ones accuser

Any evidence being used against an individual will be made available
to them. In fact, it’s explicitly required. However, it’s also clear
that confidentiality will be adhered to. This is par for the course,
at least in my experience, of any such process. The COC is also not a
criminal proceeding – there is no legal court involved – so the
emphasis is on protecting the potential complainant from additional
targeted action.

> - The CoC seems to be more concern with punitive action rather than
> establishing the values of the community.

Derick added a second section of more relevance to collaborative
values. Also, I’m on record as believing that while punitive action
need not be the central theme in a COC, it has to clear somewhere that
it CAN be employed when absolutely necessary. Hopefully never! But I
left my crystal ball at home…so I can’t rule it out.

Paddy

--
Pádraic Brady

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

Re: [PHP-DEV] [RFC][DISCUSSION] Allow default value in list() syntax

[reeze]

Bump this to continue discussion of this RFC (
https://wiki.php.net/rfc/list_default_value).

In case some of you didn't follow it before. This RFC propose to allow set
default value in list() assignment：

list($a = 'default value') = $arr;


On 10 November 2015 at 11:14, reeze  wrote:

> Hey Dan,
>
> On 9 November 2015 at 23:24, Dan Ackroyd  wrote:
>
>> Hi Reeze,
>>
>> On 9 November 2015 at 13:35, reeze  wrote:
>> > Hi internals!
>> >
>> > I'd like to open a discussion on the RFC to allow set default values for
>> > list() assignment:  https://wiki.php.net/rfc/list_default_value.
>> >
>> > What is your idea?
>>
>> I find the list construct to be quite magic already. Isn't it possible
>
> to get the affect that you want without adding anything to the core by
>> doing this:
>>
>> $defaults = ['default', 'default'];
>> $input = [1];
>>
>> list($a, $b) = array_replace($defaults, $input);
>>
>> I'd find that way easier to understand and explain to junior devs,
>>
>
> I saw the contrast way, it is more complex ;-). This seems like a trick.
> Many feature could also be remove,
> such as I refered in RFC:  Null coalesce "??" and Ternary Operator "?:"
>
> And the trick is trick. If you want to unpack nested array.
>
> list($a, list(list($b))) = $array
>
> Then you might need a new trick to do that.
>
> You know we have default for function declaration:
> function func($a='default') {}; and almost all language have the feature,
> it is easier to understand from my perspective.
>
>
>> compared to having more functionality added to the 'list' magicness.
>>
>> cheers
>> Dan
>>
>
>
>
> --
> Reeze Xia
> http://reeze.cn
>



-- 
Reeze Xia
http://reeze.cn

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

[Pádraic Brady]

Hi,

On 21 January 2016 at 07:50, Zeev Suraski  wrote:
> I think the fact that this RFC was (and still is) perceived to be a solution 
> for the toxic internals problem -  actually served the proponents of this RFC 
> very well.  On one hand, this is what people at large care about.  On the 
> other - the proponents can tell the those who oppose that it's not at all 
> what the RFC is about, and that their worries about this becoming a tool for 
> a behavioral/thought police are completely baseless.
>
> Note that despite the fact that Derick - who's now the RFC author - clearly 
> said that the reason he's reviving the RFC is because internals is toxic - 
> you're still assuming that the RFC isn't intended to 'fix mailing list 
> toxicity'.
>
> Can we get any more confused than that?

We can but try to be more confused ;). I was indeed though – my bad.
The revised RFC has two parts combined and I glossed completely over
the second:

1. The Code of Conduct (i.e. Contributor Covenant 1.3)

2. Constructive Collaboration Guidelines (i.e. somewhat “toxicity” related)

>> At a basic level, what exactly is a code of conduct where the only
>> consequence is mediation, where both parties are assumed to have good
>> will, and where the outcome is ??.
>
> My take?  A successful one.  One that we can all rally behind, as opposed to 
> a controversial one that is creating much angst.  Please see my response to 
> Andrea.
>
>> That's the a problem from my
>> perspective. What is the outcome? Does mediation continue indefinitely
>> without results?
>
> No, in the vast majority -  and I do mean VAST majority, mediation works and 
> results would be quick.  When people are told that they should cool off, they 
> typically do.  I know I would.  Even more so if that mediation team could 
> point me to a certain desired behavior I'm not quite following at that time, 
> and do so respectfully and not judgmentally.

Agreed.

>> While the mediation is ongoing for the long haul, will be
>> there be any remediation set to protect a theoretical victim? What is Plan B?
>
> I don't think we can go on discussing two completely different issues - 
> safety and 'toxicity', while jumping in between them as if they're the same 
> thing.  The way the current RFC author sets of the scope is much wider than 
> safety issues, and the use of the word 'victim' and 'remediation' are not 
> really relevant to it - at least in the vast majority of incidents we're 
> likely to experience

Apologies, that wasn’t my intent – I wasn’t referring to the
“toxicity” issue. Solely referring there to anything under the
Contributor Covenant section of the RFC. The words “victim”, etc do
apply there in the context of harassment and such.

>> Part of the COC is to explicitly limit ad-hoc reactions should things go
>> completely down the gutter by defining something upfront. By extension,
>> any uncertainty of what would happen should Person A complain may act as
>> a deterrent to making such a complaint. It could be anticipated that long
>> drawn out procedures with an unknown ending are in and of themselves
>> stressful (and to both parties to boot).
>
> There's just no way to undo the damage that the threat of penalties does when 
> the goal is trying to foster positive behavior.  Any education person - and 
> hopefully most parents - will tell you that.  Our brains respond completely 
> differently to demands and threats versus encouragement and guidance.
>
> There's no absolute winning formula, and there's no one size fits all.  Yes, 
> in an extreme, uncommon case - the fact we're focusing on desired behavior 
> and not on 'deterrence' - might cause a certain individual to feel they can 
> do a certain something and get away with it (something, that if safety issues 
> was what we're dealing with, may very well be illegal and carry criminal 
> penalties).  Is it worth to design our whole system around that extremely 
> infrequent situation *AT THE EXPENSE* of how we deal with the normal day to 
> day situations?  I know my answer.

It doesn’t need to revolve entirely around it, but it should somewhere
acknowledge it. Honestly, I don’t care if it’s one line in a footnote
in pt2 font size, so long as it’s there.

Also, loosely connected and off on a tangent perhaps, it’s important
that we don’t just expect legal consequences to solve everything at
the extreme end of the spectrum. While that avenue can certainly
exist, depending on local laws, I imagine the cost would be
prohibitive (for not outright criminal behaviour) and I really don’t
see that working well across international borders. I can only speak
to local practice and solicitor costs here on one small island, of
course.

Paddy


--
Pádraic Brady

http://blog.astrumfutura.com

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

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

[Allan MacGregor]

Padraic,

Taking a step back, instead taking a knee-jerk reaction; I think Kevin 
brought up a valid point. Is very clear that there are certain actors 
that are pushing for a specific version of this code of conduct to use 
it as a political tool.


This is it what concerns most people regarding this specific CoC; you 
want to debate the CoC proposed, fine. Personally here are my issues 
with it:


- Language is vague and open to interpretation
- There is no mechanism or ability for one to confront ones accuser
- The CoC seems to be more concern with punitive action rather than 
establishing the values of the community.


Allan.

Pádraic Brady wrote:


Hi,

On 21 January 2016 at 04:37, Kevin Smith wrote:


I noticed you were contacted by Randi Lee Harper 
[https://archive.is/b8RDW], the ironically abusive founder of the 
Online Abuse Prevention Initiative 
[https://archive.is/eqco9][http://archive.is/A1Azz] known for 
attacking and attempting to eject from projects/employment people she 
associates with groups she doesn’t approve of 
[http://archive.is/1A8SQ], wherein she suggested that you ignore the 
Code of Merit that Pavel recommended for consideration because she 
associates the author of said code with a group that—though entirely 
unrelated to his Open Source contributions—she finds undesirable and 
then proceeded to make general derogatory comments about him [again, 
https://archive.is/b8RDW].



Are you here to debate the proposed COC, or to mount personal attacks
on someone outside of the PHP community?



(My deepest apologies for such a tremendous run-on sentence.)

I certainly hope this isn’t indicative of the spirit of this 
proposal. This exchange really seems to suggest the goal of these 
codes in general, and now possibly this one in particular, is what so 
many of us have feared: to exclude people with wrong ideas and 
associations, as defined by the in-group.



Is that what the RFC actually states though? As it's a code of
conduct, it's directed at specific actions not whatever is running
through your, or my, head.

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

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

[Sascha Schumann]

> For what it's worth, I find the description 'rules for misconduct' extremely
> telling and fairly horrible way to describe a Code of Conduct, as I'm sure any
> people involved with education would agree.

Agreed.

> > But we don't really have an alternative process for this currently
> > established,
> > so an RFC is the best we can do.

Wow, you managed to dismiss +15 years of people working together, creating
something which changed the world, in just one sentence. Perplexing.

> We have clear rules which disallow revival of RFCs which failed a vote for a
> duration of six months, unless they're very substantially modified, so revival
> isn't always allowed in open source.

I think Derick is abusing the RFC process here clearly. The necessary action
should be clear based on that.

Sascha

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

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

[Zeev Suraski]

On 21 בינו׳ 2016, at 7:36, Sascha Schumann  
wrote:
.
>> We have clear rules which disallow revival of RFCs which failed a vote for a
>> duration of six months, unless they're very substantially modified, so 
>> revival
>> isn't always allowed in open source.
> 
> I think Derick is abusing the RFC process here clearly. The necessary action
> should be clear based on that.

Sascha,

While personally I think it should not be allowed and be subject to the same 
rules as rejected RFCs - the Voting process we have doesn't deal with revival 
of RFCs that were withdrawn by their author.  So I don't think Derick is 
abusing the process in that regard.

The problem is that conceptually the RFC process isn't designed to handle 
issues like this.  Abuse may be an overkill to describe it - but it's clearly 
something that should not be done.

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

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

[Andrea Faulds]

Hi Stas,

Stanislav Malyshev wrote:

Hi!


It might leave others feeling pressured, but it's not their fault if
those contributors feel unsafe without a code of conduct. Nor is the


I don't want to be dismissive, but I do not see anything on the list
that should make anybody feel *unsafe* (unless of course I misunderstand
what you mean by "unsafe", in which case please correct me).
Uncomfortable - sure, exhausted and exasperated - oh yes, but unsafe?
I mean, everybody has the right to *feel* whatever they like, but I
don't see how we can accept any responsibility for those feelings if
they have no base in anything that actually happened? I feel like more
insight into this would definitely be useful - what concerns about
safety we have and CoC would fix?


Safety isn't usually something people have to worry about with the list, 
I think. Usually we're civil.


That being said, the CoC discussion seems to have attracted attention 
from other parts of the Internet, and at least I, personally, do not 
feel entirely safe speaking out about it now because I fear becoming the 
newest target of online harassment from right-wing groups. This 
discussion is already being watched by them.


I can't really talk about other people's motives for not contributing, 
however. Certainly safety isn't the only concern people might have.



flip-side true: a certain person said they fear getting in trouble for
their political views if the CoC passes, and if they wanted to leave as
a result, so be it. Nobody is under any obligation to contribute to PHP,
they can freely choose not to contribute if they wish, and that is their
right.


That is certainly true, in general. In particular, though, the argument
"do as I tell, or I'll take my toys and leave" is not a very
constructive approach, because it leaves no space for seeking compromise
- either you do exactly as you told to, fully submitting to whatever the
other person says to do, or no collaboration happens ever. While on some
(very small set of) questions it may be the way to go, in most areas I
don't think this is a fair way to do things.


It's not a nice way to conduct negotiations, but I don't think this is a 
deliberate attempt at forcing people to accept a code of conduct. 
Rather, I think people who have said they might leave do so because they 
have gotten sick of the "toxicity" of the list and are the code of 
conduct being rejected because of it would be a last straw. I can't 
claim to speak for them, though, so I'll stop talking about this.


It comes off as manipulative, but what can be done? Would it be better 
to silently disappear after a code of conduct is rejected?





Personally, I don't see how expanding from covering serious misbehavior
(harassment etc.) to covering more generally
non-conducive-to-civil-discussion actions would make things more or less


Very easily. Instead of discussing things on merits, people start
rule-laywering and offense-sniping each other. In fact, we see this
happening from time to time even now, when people who dislike RFC try to
argue against it on technicalities, and I think it does not improve
matters, but if we officially enshrine this as a policy, this would grow
tenfold. It is much easier to say "she is posting too often!" or "he
disagrees with me too much and I feel offended and threatened!" and try
to shut the opponent up than to address the matter of disagreement. So
we are creating motivation for destructive behavior. This needs to be
addressed.


Ah, actually I can see what you're getting at. It does sometimes happen 
that people complain about how others are behaving in discussions, 
others who disagree with them. But I think often those concerns are 
quite valid nonetheless... surely it must be possible to design things 
so that dealing with such behaviour doesn't give the opposing side an 
unfortunate advantage. Perhaps if you were to temporarily ban someone 
from the list, say, it would delay the RFC they were dicussing. It must 
be possible to deal with people's behaviour separately from their 
technical opinions. I worry if people can be immune from criticism 
because they favour a particular side of a technical argument.


That's just a very quick thought though, don't take it as a concrete 
proposal, it's more a musing.



Even if you believe that it's not a problem, that doesn't change the
opinion of people who do think that an unenforced code of conduct is
problematic.


Worse than not having any at all?


It could be, it's arguable. If you have a set of rules but nothing is 
done if they are violated, then someone who sees the set of rules and is 
unaware they are unenforced might be given a false impression.


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] [VOTE] Class Constant Visibility

[Michael Wallner]

On 21/01/16 06:36, Xinchen Hui wrote:
> Hey:
> 
> On Wed, Jan 20, 2016 at 7:05 PM, Michael Wallner  > wrote:
> 
> On 08/12/15 10:56, Dmitry Stogov wrote:
> > Hi Sean,
> >
> > The PR has been merged into master.
> > Please update the RFC accordingly.
> > Thanks to Nikita and Xinchen for code review and suggestions.
> >
> 
> 
> This patch seems to cause problems for me with registering constants on
> internal interfaces; see bug #71413 https://bugs.php.net/71413
> 
> this should be fixed in :
> https://github.com/php/php-src/commit/62c1c11ad34103729988df9edea343337a900ba9

Confirmed. Thank you!


-- 
Regards,
Mike

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

[PHP-DEV] PDO Close Connection

[Gabriel Zerbib]

Hi, list!

This is my first email to this mailing list, so please pardon me for misuse
of the traditions you may have here (formatting, phrasing, etc.).

Maybe this has been discussed in depth earlier, but: I want to ask if there
is an explicit reason for not giving a "close" instance method in the PDO
class.

The Web is full of wrong disputes about why one would want to explicitly
close a PDO connection, since it is auto-released at end of script
life-cycle. Of course this is wrong, because among many other use cases,
for example a long running script (daemon-like) may want to free a DB
Connection slot when they know they have to sleep for some time.

The manual says that one has to assign to null, the variable retaining the
PDO instance. One also has to null out all the variables holding a
statement coming from that PDO instance).

IMHO this is not good practice enough, especially given the way many PHP
developers (mis)understand reference counting and variables.

$a = new PDO(...);
$b = $a;
$a = null;

This above snippet will not close the connection when assigning $a = null;
(at list not until PHP 5.6 incl).

In an application made of dependency injection, closures and many levels of
function calls split over many files, it is virtually impossible to keep
reference counting mentally, and you mostly end up never knowing what other
component of the application still retains a reference to the PDO object.
And yet, in some use cases, you still know that you want to release the
connection before going to sleep or doing a lengthy operation (which might
anyway cause a "Sql server has gone away", so you're better off not
occupying a DBMS connection slot for nothing during the lengthy operation.


I think it could be recommended to export a "closeConnection" method.

I would be happy to know what people think (and pardon me again if the
debate has been conducted already : please guide me to the corresponding
literature?)
If it is of any interest, what would be the next step? For me to open an
RFC?

Thanks,
Regards,
Gabriel

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

[Pavel Kouřil]

On Wed, Jan 20, 2016 at 10:20 PM, Derick Rethans  wrote:
> On Wed, 20 Jan 2016, Pavel Kouřil wrote:
>
>> On Wed, Jan 20, 2016 at 8:04 PM, Derick Rethans  
>> wrote:
>> >
>> > I've decided to re-propose the CoC RFC. There are many reasons for it,
>> > but there are a few points I want to make.
>>
>> if you still insists on some CoC, maybe you could at least look into
>> something else than the "Contributor Covenant"?
>>
>> For example, http://code-of-merit.org/ seems much more reasonable in
>> "getting the things done" than the Covenant.
>
> Sure - I would very much appreciate a list of things to look at. Would
> you have time to suggest a list with C of C's? It is unlikely that one
> will cover it all anyway. Something that (stolen the idea from twitter)
> has a good list of *positive* core values is also in my opinion
> important to have.
>
> cheers,
> Derick

Hi,

unfortunately, I don't have time for that (or at least not now). :(

The other thing is, I honestly don't believe you even need a CoC - and
if you really DO need it, it should be as short as possible, basically
something like "write code/rfcs, politely discuss it and don't discuss
anything not related to project on project forums/mailing lists/etc."
should be totally enough. The longer the CoC gets, the more "clutter"
it will have - as you can see in the Covenant.

(This is why I find the Code of Merit much better than Covenant, even
though it is IMHO still too long - and the fact it doesn't have
approximately 1/3 or 1/4 of the text dedicated to listing abusive
behavior and the general equality stuff, like Covenant does. And that
it doesn't try to control people outside of the project.)

Regards
PK

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

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

[Andrea Faulds]

Hi Allan,

Allan MacGregor wrote:


The Code of Merit essentially creates an armour clad


rejection of any non-technical topic.

Is really that bad, this is an open source project. We are talking about
a programming language not a socio-political movement? Or did I missed
the memo?


An open-source project is not merely a bundle of code, but also a 
community that maintains it. As with any social group created by humans, 
you will always have to discuss things related to the group itself as well.



When it comes down to PHP itself the main concern should be the language
and the development of the project.


Indeed, and towards that end, it is sometimes necessary to have meta 
discussions. Projects are, after all, composed of people, not binary blobs.


If we fail to successfully manage a community, then the project will die 
or be taken up by another group. So far we seem to have not done 
absolutely terribly, or there wouldn't be a discussion here. We didn't 
reach this point by never, ever talking about non-technical matters.


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] [Re-proposed] Adopt Code of Conduct

[Andrea Faulds]

Paul M. Jones wrote:

That's a nice try, but since the Contributor Covenant is a political document, the politics of 
those who favor it are fair game.  Also, your attempt to characterize "quoting someone's own 
words" as "personal attacks" is noted.


Inherently, any discussion concerning interactions between people is 
"political". Politics is not the exclusive domain of states, it's a 
feature of any and every social group.


And unfortunately, any document which says that you can't discriminate 
is political, any document which says harassment is wrong is political, 
in fact anything which proscribes any behaviour of any kind is political.


Also, arguing against a code of conduct is, in itself, also political. 
If you don't think a code of conduct is necessary, it's a political 
statement, just as being in favour of one is.


So, basically, what I'm saying that complaining something involves 
"politics" is fruitless, because of course it does. Instead, argue your 
case for why the "politics" of it is - that is, the content - is bad. If 
it happens to be written by people who disagree from your political 
persuasion, that would be immaterial. The content is what is being 
discussed and potentially adopted, not the author's personal views.


--
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] [Re-proposed] Adopt Code of Conduct

[Andrea Faulds]

Dan,

Dan Ackroyd wrote:

On 21 January 2016 at 07:06, Zeev Suraski  wrote:

We have clear rules which disallow revival of RFCs which failed a vote for a 
duration of six months, unless they're very substantially modified, so revival 
isn't always allowed in open source.



As other people have noted, the RFC never went to vote, so it was
never rejected.

But even if it had been, the actual text is you're claiming as a clear rule is:

"it will not be allowed to bring up a rejected proposal up for another
vote, unless...The author(s) make substantial changes to the
proposal."

There is absolutely no rule against being allowed to discuss
something. The only rule is about putting stuff to a vote repeatedly.


This is true, but Ze'ev acknowledged that already.

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

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

Re: [PHP-DEV] PHP 7.0.3 RC1 is available for testing - **** BC break ***

[Remi Collet]

Le 21/01/2016 11:53, Anatol Belski a écrit :
> Hi,
> 
> PHP 7.0.3 RC1 was just released and can be downloaded from:

Fedora detected a BC break in 5.6.18RC1 and 7.0.3RC1 related to
session management.

This update breaks:

Horde_SessionHandler (2.2.6) and symfony (2.7.9)

https://apps.fedoraproject.org/koschei/package/php-horde-Horde-SessionHandler

+ /usr/bin/phpunit .
PHPUnit 4.8.17 by Sebastian Bergmann and contributors.
.FE.ESPHP Warning:  session_destroy(): Trying to destroy uninitialized
session in
/builddir/build/BUILD/php-horde-Horde-SessionHandler-2.2.6/Horde_SessionHandler-2.2.6/test/Horde/SessionHandler/Storage/BuiltinTest.php
on line 115
......
Time: 231 ms, Memory: 5.00Mb
There were 2 errors:
1) Horde_SessionHandler_Storage_BuiltinTest::testReopen
Undefined index: sessiondata
/builddir/build/BUILD/php-horde-Horde-SessionHandler-2.2.6/Horde_SessionHandler-2.2.6/test/Horde/SessionHandler/Storage/BuiltinTest.php:45
2) Horde_SessionHandler_Storage_BuiltinTest::testDestroy
session_destroy(): Trying to destroy uninitialized session
/builddir/build/BUILD/php-horde-Horde-SessionHandler-2.2.6/Horde_SessionHandler-2.2.6/test/Horde/SessionHandler/Storage/BuiltinTest.php:79
--
There was 1 failure:
1) Horde_SessionHandler_Storage_BuiltinTest::testRead
Failed asserting that two strings are equal.
--- Expected
+++ Actual
@@ @@
-'sessiondata|s:3:"foo";'
+''
/builddir/build/BUILD/php-horde-Horde-SessionHandler-2.2.6/Horde_SessionHandler-2.2.6/test/Horde/SessionHandler/Storage/BuiltinTest.php:33
FAILURES!
Tests: 36, Assertions: 84, Errors: 2, Failures: 1, Skipped: 37.
PHP Warning:  session_destroy(): Trying to destroy uninitialized
session in /usr/share/pear/Horde/Cli.php on line 530


+ /usr/bin/php -d
include_path=.:/builddir/build/BUILDROOT/php-symfony-2.7.9-2.fc24.noarch/usr/share/php:/usr/share/php
/usr/bin/phpunit --exclude-group benchmark,intl-data,tty --bootstrap
bootstrap.php
/builddir/build/BUILDROOT/php-symfony-2.7.9-2.fc24.noarch/usr/share/php/Symfony/Component/HttpKernel
PHPUnit 4.8.17 by Sebastian Bergmann and contributors.
.FDumpDataCollectorTest.php on
line 89:
123
.  63 / 440 ( 14%)
... 126 /
440 ( 28%)
... 189 /
440 ( 42%)
... 252 /
440 ( 57%)
... 315 /
440 ( 71%)
... 378 /
440 ( 85%)
.SS...
Time: 17.34 seconds, Memory: 17.00Mb
There was 1 failure:
1)
Symfony\Component\HttpKernel\Tests\DataCollector\DumpDataCollectorTest::testCollectHtml
Failed asserting that two strings are identical.
--- Expected
+++ Actual
@@ @@
- DumpDataCollectorTest.php on line 89:
+  on line 89:
 123
 
/builddir/build/BUILDROOT/php-symfony-2.7.9-2.fc24.noarch/usr/share/php/Symfony/Component/HttpKernel/Tests/DataCollector/DumpDataCollectorTest.php:118
FAILURES!
Tests: 746, Assertions: 1310, Failures: 1, Skipped: 18.
Legacy deprecation notices (11)
>>> 
/builddir/build/BUILDROOT/php-symfony-2.7.9-2.fc24.noarch/usr/share/php/Symfony/Component/Intl
+ RET=1


Of course, both test suites were OK with 5.6.17.

Remi.


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

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

[Stanislav Malyshev]

Hi!

> That's a nice try, but since the Contributor Covenant is a political
> document, the politics of those who favor it are fair game.  Also,

I don't think we need to discuss politics here, at least "politics of
those", i.e. personal views rather than merits of specific proposals. I
see no good that can come out of it. I think we know there are some
agents out there (not here on the list) that have interests outside of
the well-being of this community, and I think that's as far as we should
go in discussing them here, going further IMO won't help any.

Yes, the code - whatever its formula ends up being - is a political
document in its essence, as it aims to describe our goals, behavioral
patterns, social agreements and mores, etc. - which is ultimately what
politics is about. However, that does not mean we should bring in
political discussions not related to out community, I think it would not
help.
-- 
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] [Re-proposed] Adopt Code of Conduct

[Allan MacGregor]

Hi,

Pádraic Brady 
January 21, 2016 at 10:59 AM
Hi,

On 21 January 2016 at 14:33, Allan MacGregor
  wrote:

Padraic,

Taking a step back, instead taking a knee-jerk reaction; I think Kevin
brought up a valid point. Is very clear that there are certain actors that
are pushing for a specific version of this code of conduct to use it as a
political tool.


The RFC has actual text, which can be read, examined and discussed.
There is no need whatsoever to drag in anything beyond unless directly
relevant to the text at hand. Personal attacks on people who support a
COC, or do not support a COC, aren't productive. If there is a
political plot to undermine whatever in PHP, then please do support
this by quoting from the RFC.
Let's discuss the CoC at hand. Is my opinion that the current text based 
on the Contributors Covenant 1.3 is too broad on its scope and the 
punitive actions. What do I mean too broad? well I think the CoC needs 
to define what a project channel/space is; as well there should be a 
clarification that contributors are entitled to their political views 
and opinions outside of these channels.


With that in mind I'm attaching the following draft that extends the 
definition of the second paragraph and attempts to define that the 
official project channels are 
https://gist.github.com/amacgregor/16c62908ff39f51604e2 in short:


We are committed to evaluating contributions within project channels 
(such as reporting issues, posting feature requests, updating 
documentation, submitting pull requests or patches, and other project 
activities) without regard to the contributor's level of experience, 
gender, gender identity and expression, sexual orientation, disability, 
personal appearance, body size, race, ethnicity, age, religion, 
nationality, politics, or activity outside of project channels.


The following are considered the official project channels:

 * PHP Mailing list
 * PHP Official IRC Channel
 * PHP Official repositories
 * PHP Official social media accounts

Based on paul's earlier post http://news.php.net/php.internals/90259

This is it what concerns most people regarding this specific CoC; you want
to debate the CoC proposed, fine. Personally here are my issues with it:

- Language is vague and open to interpretation


Propose specific text which also addresses harassment and the other
not vague words. I’m sure people will happily read and review it.

  >  - There is no mechanism or ability for one to confront ones accuser

Any evidence being used against an individual will be made available
to them. In fact, it’s explicitly required. However, it’s also clear
that confidentiality will be adhered to. This is par for the course,
at least in my experience, of any such process. The COC is also not a
criminal proceeding – there is no legal court involved – so the
emphasis is on protecting the potential complainant from additional
targeted action.
That might be the case, but we are talking about applying sanctions with 
real world repercussions and as such having a confrontation clause or at 
least the right to cross examination and face my accuser.


– so the emphasis is on protecting the potential complainant from 
additional targeted action.


If the emphasis is on fairness, equality and justice, then you have to 
protect the rights of the accused and the accuser.



- The CoC seems to be more concern with punitive action rather than
establishing the values of the community.


Derick added a second section of more relevance to collaborative
values. Also, I’m on record as believing that while punitive action
need not be the central theme in a COC, it has to clear somewhere that
it CAN be employed when absolutely necessary. Hopefully never! But I
left my crystal ball at home…so I can’t rule it out.

Paddy

--
Pádraic Brady
Allan MacGregor 
January 21, 2016 at 9:33 AM
Padraic,

Taking a step back, instead taking a knee-jerk reaction; I think Kevin 
brought up a valid point. Is very clear that there are certain actors 
that are pushing for a specific version of this code of conduct to use 
it as a political tool.


This is it what concerns most people regarding this specific CoC; you 
want to debate the CoC proposed, fine. Personally here are my issues 
with it:


- Language is vague and open to interpretation
- There is no mechanism or ability for one to confront ones accuser
- The CoC seems to be more concern with punitive action rather than 
establishing the values of the community.


Allan.

Pádraic Brady wrote:
Pádraic Brady 
January 21, 2016 at 7:19 AM
Hi,

On 21 January 2016 at 04:37, Kevin Smith  wrote:

I noticed you were contacted by Randi Lee Harper [https://archive.is/b8RDW], 
the ironically abusive founder of the Online Abuse Prevention Initiative 
[https://archive.is/eqco9][http://archive.is/A1Azz] known for attacking 

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

[Paul M. Jones]

> On Jan 21, 2016, at 09:59, Pádraic Brady  wrote:
> 
> Hi,
> 
> On 21 January 2016 at 14:33, Allan MacGregor
>  wrote:
>> Padraic,
>> 
>> Taking a step back, instead taking a knee-jerk reaction; I think Kevin
>> brought up a valid point. Is very clear that there are certain actors that
>> are pushing for a specific version of this code of conduct to use it as a
>> political tool.
> 
> The RFC has actual text, which can be read, examined and discussed.
> There is no need whatsoever to drag in anything beyond unless directly
> relevant to the text at hand. Personal attacks on people who support a
> COC, or do not support a COC, aren't productive. If there is a
> political plot to undermine whatever in PHP, then please do support
> this by quoting from the RFC.

That's a nice try, but since the Contributor Covenant is a political document, 
the politics of those who favor it are fair game.  Also, your attempt to 
characterize "quoting someone's own words" as "personal attacks" is noted.



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

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

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



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

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

[Zeev Suraski]

>> On 21 בינו׳ 2016, at 9:54, Andrea Faulds  wrote:
>> 
>> There is absolutely no rule against being allowed to discuss
>> something. The only rule is about putting stuff to a vote repeatedly.
> 
> This is true, but Ze'ev acknowledged that already.

I've more than acknowledged that already - I said it right off the bat:

"Yes, I realize the Voting RFC doesn't state that.  I'm stating my opinion."

This entire email was unnecessary as it created the wrong impression that I was 
claiming this wasn't allowed - when what I said was that in my opinion, it was 
wrong and shouldn't be done.

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

Re: [PHP-DEV] PHP 7.0.3 RC1 is available for testing - **** BC break ***

[Stanislav Malyshev]

Hi!

> Fedora detected a BC break in 5.6.18RC1 and 7.0.3RC1 related to
> session management.

Looks like something to do with last session changes. Yasuo, could you
take a look at 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] [Re-proposed] Adopt Code of Conduct

[Paul M. Jones]

> On Jan 21, 2016, at 09:46, Derick Rethans  wrote:
> 
>> - There is no mechanism or ability for one to confront ones accuser
> 
> That is a tricky one. In my opinion, in the case of abuse as pointed out 
> in the draft CoC, I think this is fair, and necessary that we all for 
> reports of abuse in private, and with secrecy. Without it, an accusor is 
> likely immediately going to be lambasted by the perpetrator. 

Here we have the core of (yet another) problem: presumption of guilt. The 
"accused" is casually referred to as the "perpetrator."  This is *exactly* why 
the accused needs to be able to confront the accuser.

The common reply here is to say "oops, sorry, I meant to say 'the accused'".  I 
don't think that's true; it's a wink-and-a-nod, a recognition that one has 
revealed their true thoughts: all accusations are to be believed. Except, of 
course, the ones that are not to be believed, and those will (strangely enough) 
line up with the political beliefs of the enforcers. Because it is a political 
document, the Contributor Covenant is *intended* to work that way.

That is only one of the many reasons the Contributor Covenant, and all 
documents like it, should be removed in toto from any Code of Conduct 
discussion.


-- 
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] WIKI: phpng-upgrading

[Nikita Popov]

On Wed, Jan 20, 2016 at 11:07 PM, Sean DuBois  wrote:

> Hi!
>
> I tried to get access to that page as well, but didn't have any luck
> would you mind adding the zend_parse_paramaters changes?
>
> 'l' went from 'long' -> 'zend_long' and 's' went from 'int' -> 'size_t'.
>
> So many extensions have been ported without this in mind, and it bites
> in really nasty hard to reproduce runtime ways.
>

I've added these two to the zpp section, thanks!

Nikita

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

[Eli]

On 1/21/16 10:04 AM, Zeev Suraski wrote:
> On 21 בינו׳ 2016, at 7:36, Sascha Schumann  
> wrote:
> .
>>> We have clear rules which disallow revival of RFCs which failed a vote for a
>>> duration of six months, unless they're very substantially modified, so 
>>> revival
>>> isn't always allowed in open source.
>> I think Derick is abusing the RFC process here clearly. The necessary action
>> should be clear based on that.
> Sascha,
>
> While personally I think it should not be allowed and be subject to the same 
> rules as rejected RFCs - the Voting process we have doesn't deal with revival 
> of RFCs that were withdrawn by their author.  So I don't think Derick is 
> abusing the process in that regard.
>
> The problem is that conceptually the RFC process isn't designed to handle 
> issues like this.  Abuse may be an overkill to describe it - but it's clearly 
> something that should not be done.
>
> Zeev

I do need to speak on this point.  And mirror in effect the words of
Andrea.  Someone choosing to withdraw an RFC, for any reason (such as,
but not limited to: personal health, life crisis, feeling bullied, etc.)

Is not an indication that an RFC failed, in any way.  So no 6-month ban
should be in place for that.   If that existed in fact, then multiple
issues could come from that, including bullying someone to drop an RFC
as an effective way of fighting one you didn't like.  OR  The idea of
opening an RFC quickly on a topic that you actually don't like, then
withdrawing it later before it goes to vote, just to stop discussion for
6 months.

I agree that there isn't any current process/policy in place to handle
this, and maybe, or maybe not, there should be.   However, just
considering a RFC 'failed' because a person had reason to back out of
running it themselves, should not be the end result.

Thanks,
Eli


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




signature.asc
Description: OpenPGP digital signature

[PHP-DEV] VCS Account Request: mprelude

[Matt Prelude]

To contribute bugfixes to PHP.


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

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

[Dan Ackroyd]

On 21 January 2016 at 07:06, Zeev Suraski  wrote:
> We have clear rules which disallow revival of RFCs which failed a vote for a 
> duration of six months, unless they're very substantially modified, so 
> revival isn't always allowed in open source.


As other people have noted, the RFC never went to vote, so it was
never rejected.

But even if it had been, the actual text is you're claiming as a clear rule is:

"it will not be allowed to bring up a rejected proposal up for another
vote, unless...The author(s) make substantial changes to the
proposal."

There is absolutely no rule against being allowed to discuss
something. The only rule is about putting stuff to a vote repeatedly.

aka please don't try to shut down conversations you don't like.

cheers
Dan

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

Re: [PHP-DEV] Handling of withdrawn RFCs

[Ronald Chmara]

On Thu, Jan 21, 2016 at 12:33 PM, Flyingmana  wrote:
> An RFC could still be valuable for the project, even if the original
> author leaved, so taking it over should be possible. And it should not
> be painful in any way.
> Would we need some rules in case multiple people want to take it over,
> or should we say the first one wins?
> Is there any way to abuse the taking over of an withdrawn RFC?

Hypothetically:

An RFC being used primarily for ongoing debate/argument/trolling
purposes could live indefinitely, generating hundreds, or thousands,
of messages, and changesets/PR's, and list churn, in the name of
"making sure an issue is adequately discussed and resolved".

Even as individual trolls, marks, and sockpuppets were knocked down,
new ones could pick up the mantle of "but we're discussing important
things, here!", and continue the loop, only finally exhausting the
suite of RFC mechanisms all of the trolls/marks/puppets finally gave
up, or were someho0w being administratively prohibited from all future
participation.

Which, if the PHP email lists were an endless trolling/argument/debate
forum like twitter or reddit, would be completely appropriate.

This is all hypothetical, of course.

-Ronabop

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

Re: [PHP-DEV] Handling of withdrawn RFCs

[Peter Lind]

On 21 January 2016 at 21:53, Ronald Chmara  wrote:

> On Thu, Jan 21, 2016 at 12:33 PM, Flyingmana 
> wrote:
> > An RFC could still be valuable for the project, even if the original
> > author leaved, so taking it over should be possible. And it should not
> > be painful in any way.
> > Would we need some rules in case multiple people want to take it over,
> > or should we say the first one wins?
> > Is there any way to abuse the taking over of an withdrawn RFC?
>
> Hypothetically:
>
> An RFC being used primarily for ongoing debate/argument/trolling
> purposes could live indefinitely, generating hundreds, or thousands,
> of messages, and changesets/PR's, and list churn, in the name of
> "making sure an issue is adequately discussed and resolved".
>
> Even as individual trolls, marks, and sockpuppets were knocked down,
> new ones could pick up the mantle of "but we're discussing important
> things, here!", and continue the loop, only finally exhausting the
> suite of RFC mechanisms all of the trolls/marks/puppets finally gave
> up, or were someho0w being administratively prohibited from all future
> participation.
>
> Which, if the PHP email lists were an endless trolling/argument/debate
> forum like twitter or reddit, would be completely appropriate.
>
> This is all hypothetical, of course.
>
>
This thread being about withdrawn/re-proposed RFCs, how is that comment
relevant? Seeing as anyone wanting to debate/argument/troll indefinitely
can do so using their own RFC - or, for that matter, without an RFC.

Regards
Peter


-- 

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

[PHP-DEV] Handling of withdrawn RFCs

[Flyingmana]

There seems to be some different point of views how to handle withdrawn
RFCs. As this is a separate point and maybe a more complex point I want
to start this as an additional Thread here.

The Goal is, to not have this argument again against someone taking over
a withdrawn RFC. Means this should end in some rules/guidelines
regarding RFCs. (Advice what would be needed, like for example an RFC,
is very welcome)

As already was noted by someone else, seeing an RFC as failed if it gets
withdrawn has some serious downsides and potential to get abused.

Most obvious the possibility to kill RFCs by increased pressure against
the author. I think that deserves to get targeted, as leading an RFC
which gets some greater public attention creates in itself already some
pressure, not everyone is able to endure.

An RFC could still be valuable for the project, even if the original
author leaved, so taking it over should be possible. And it should not
be painful in any way.


Would we need some rules in case multiple people want to take it over,
or should we say the first one wins?

Is there any way to abuse the taking over of an withdrawn RFC?

best Regards,
Flyingmana

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

Re: [PHP-DEV] PHP 7.0.3 RC1 is available for testing - **** BC break ***

[Stanislav Malyshev]

Hi!

> We have 2 choices
>  - Enforce new and correct behavior since it will not affect normal
>operation. i.e. Actual production site
>  - Restore old behavior for the time being. (For this option, I prefer
>to restore only for PHP 5.6, but Ok for PHP 7.0 also. No for master)

Since it breaks applications, the existing behavior must be restored for
both 5.6 and 7.0, unless it can be fixed ASAP. For master, a note should
be made in UPGRADING at least, but if it's substantial change that
requires applications to change then RFC would be requires 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] Handling of withdrawn RFCs

[François Laupretre]

Hi,

Le 21/01/2016 21:33, Flyingmana a écrit :


As already was noted by someone else, seeing an RFC as failed if it gets
withdrawn has some serious downsides and potential to get abused.

>...

Would we need some rules in case multiple people want to take it over,
or should we say the first one wins?

Is there any way to abuse the taking over of an withdrawn RFC?


IMO, a withdrawn RFC should not be considered as failed and, unless it 
contains a more precise status ('suspended until ...', 'waiting for 
...'), it can be taken over by anybody. It is fair to ask the original 
author's permission but not sure this must be required.


I would propose a minimal period between withdrawal and takeover (48 
hours, 72 hours ?). This could prevent lightning-fast takeover to be 
used as a political trick. During this period, people could volunteer 
for taking over the RFC but the RFC itself would be frozen.


If multiple people want to take over, and if they cannot agree on 
co-authoring, the only fair solution is probably to create concurrent 
follow-up RFCs. The STH case shows that it should be avoided as much as 
possible but I'm still looking for a better solution.


Regards

François

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

Re: [PHP-DEV] [RFC][DISCUSSION] Allow default value in list() syntax

[randomly there]

On 1/21/2016 8:49 AM, reeze wrote:
> Bump this to continue discussion of this RFC (
> https://wiki.php.net/rfc/list_default_value).
>
> In case some of you didn't follow it before. This RFC propose to allow set
> default value in list() assignment：
>
> list($a = 'default value') = $arr;
>

tl;dr - List is like a contract that the array must honor.

This would seem to me a bad idea as it is already difficult enough getting
people to not think of list() as a function, but as a construct that
imports to named variables elements from an array.

You should also likely only be using list for arrays with known structures,
otherwise how do you know you're defaulting the right variable? Do you
default in front, or in back? Which values are missing from the array that
should be imported to variables and why? Should you not be populating the
array with default values?

For this to even be discussed, I feel like there would need to be a few
concrete examples of how this would be useful. If you're passing an array
to the list construct, you're telling PHP that you know how many values are
in it, and that you want them all to be filled with a value.

For example, in a dynamically generated array, the value that is missing
may be in the middle, but you can't determine where the missing value is,
only that the array is not the appropriate length.

If it's the result of a database query, the query should be returning all
values that will be populated into variables, anything missing is itself
incorrect, and building the list construct in a way to handle the data
being incorrect seems counterproductive. Instead the query should return
all the data that is expected by the construct. List is like a contract
that the array must honor.

Also, what happens when you feed a defaulted list construct bad input that
would currently result in the values being set to NULL? Would they still be
set to NULL, or would they be populated with the default value provided?

Adjusting the example from the documentation:
// list() doesn't work with strings
list($bar = 'default') = "abcde";
var_dump($bar); // NULL

or

var_dump($bar); // string(7) "default"

Sorry if this got a little long. Definitely think there needs to be some
justification behind it, though, and concrete examples of usefulness as
mentioned earlier. And generally speaking, I think treating constructs as
functions in terms of definition should be avoided.

Thanks.
Chris

Re: [PHP-DEV] PHP 7.0.3 RC1 is available for testing - **** BC break ***

[Yasuo Ohgaki]

HI Remi and all,

The reason of this BC I can think of immediately is location of GC.

GC was performed after session read previously. GC is moved before
session read because previous logic is buggy.

Old behavior:
 - Do session read (Session data is initialized and store in memory)
 - Do session GC. (Previously read session data is deleted because it
   should be removed)
 - Obsolete session data is written and alive.

New behavior:
 - Do session GC. (All obsolete data is removed)
 - Do session read (Obsolete data is gone. Initialize empty $_SESSION)
 - Newly created $_SESSION is used and obsolete session data is gone.

I think the reported BC would be fixed by moving GC location in
previous place. In fact, I had to fix phpt by the change.

Old behavior may activate obsolete (should be deleted session). This is wrong.
This could happen in low traffic sites more often.

We have 2 choices
 - Enforce new and correct behavior since it will not affect normal
   operation. i.e. Actual production site
 - Restore old behavior for the time being. (For this option, I prefer
   to restore only for PHP 5.6, but Ok for PHP 7.0 also. No for master)

Since current session module does not manage session data expiration precisely,
restoring old behavior makes sense as we don't have to/cannot be
strict about session
data management anyway.

Patch for fixing BC would be this, if I'm correct about the cause.

e8f1c29cc96ce333fa808aba126297b77d94abdf  (main patch)
57be57ac94ef46fa7a73889a1e7d6e75aa4ab00f  (TSRM fix for PHP 5.6)

I appreciate if you could run tests without these patches! Thanks.

Any comments?

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


On Fri, Jan 22, 2016 at 1:20 AM, Remi Collet  wrote:
> Le 21/01/2016 11:53, Anatol Belski a écrit :
>> Hi,
>>
>> PHP 7.0.3 RC1 was just released and can be downloaded from:
>
> Fedora detected a BC break in 5.6.18RC1 and 7.0.3RC1 related to
> session management.
>
> This update breaks:
>
> Horde_SessionHandler (2.2.6) and symfony (2.7.9)
>
> https://apps.fedoraproject.org/koschei/package/php-horde-Horde-SessionHandler
>
> + /usr/bin/phpunit .
> PHPUnit 4.8.17 by Sebastian Bergmann and contributors.
> .FE.ESPHP Warning:  session_destroy(): Trying to destroy uninitialized
> session in
> /builddir/build/BUILD/php-horde-Horde-SessionHandler-2.2.6/Horde_SessionHandler-2.2.6/test/Horde/SessionHandler/Storage/BuiltinTest.php
> on line 115
> ......
> Time: 231 ms, Memory: 5.00Mb
> There were 2 errors:
> 1) Horde_SessionHandler_Storage_BuiltinTest::testReopen
> Undefined index: sessiondata
> /builddir/build/BUILD/php-horde-Horde-SessionHandler-2.2.6/Horde_SessionHandler-2.2.6/test/Horde/SessionHandler/Storage/BuiltinTest.php:45
> 2) Horde_SessionHandler_Storage_BuiltinTest::testDestroy
> session_destroy(): Trying to destroy uninitialized session
> /builddir/build/BUILD/php-horde-Horde-SessionHandler-2.2.6/Horde_SessionHandler-2.2.6/test/Horde/SessionHandler/Storage/BuiltinTest.php:79
> --
> There was 1 failure:
> 1) Horde_SessionHandler_Storage_BuiltinTest::testRead
> Failed asserting that two strings are equal.
> --- Expected
> +++ Actual
> @@ @@
> -'sessiondata|s:3:"foo";'
> +''
> /builddir/build/BUILD/php-horde-Horde-SessionHandler-2.2.6/Horde_SessionHandler-2.2.6/test/Horde/SessionHandler/Storage/BuiltinTest.php:33
> FAILURES!
> Tests: 36, Assertions: 84, Errors: 2, Failures: 1, Skipped: 37.
> PHP Warning:  session_destroy(): Trying to destroy uninitialized
> session in /usr/share/pear/Horde/Cli.php on line 530
>
>
> + /usr/bin/php -d
> include_path=.:/builddir/build/BUILDROOT/php-symfony-2.7.9-2.fc24.noarch/usr/share/php:/usr/share/php
> /usr/bin/phpunit --exclude-group benchmark,intl-data,tty --bootstrap
> bootstrap.php
> /builddir/build/BUILDROOT/php-symfony-2.7.9-2.fc24.noarch/usr/share/php/Symfony/Component/HttpKernel
> PHPUnit 4.8.17 by Sebastian Bergmann and contributors.
> .FDumpDataCollectorTest.php on
> line 89:
> 123
> .  63 / 440 ( 14%)
> ... 126 /
> 440 ( 28%)
> ... 189 /
> 440 ( 42%)
> ... 252 /
> 440 ( 57%)
> ... 315 /
> 440 ( 71%)
> ... 378 /
> 440 ( 85%)
> .SS...
> Time: 17.34 seconds, Memory: 17.00Mb
> There was 1 failure:
> 1)
> Symfony\Component\HttpKernel\Tests\DataCollector\DumpDataCollectorTest::testCollectHtml
> Failed asserting that two strings are identical.
> --- Expected
> +++ Actual
> @@ @@
> -  href="test:///builddir/build/BUILDROOT/php-symfony-2.7.9-2.fc24.noarch/usr/share/php/Symfony/Component/HttpKernel/Tests/DataCollector/DumpDataCollectorTest.php:89"
> 

Re: [PHP-DEV] Handling of withdrawn RFCs

[Flyingmana]

On 01/21/2016 09:53 PM, Ronald Chmara wrote:

> On Thu, Jan 21, 2016 at 12:33 PM, Flyingmana  
> wrote:
>> An RFC could still be valuable for the project, even if the original
>> author leaved, so taking it over should be possible. And it should not
>> be painful in any way.
>> Would we need some rules in case multiple people want to take it over,
>> or should we say the first one wins?
>> Is there any way to abuse the taking over of an withdrawn RFC?
> 
> Hypothetically:
> 
> An RFC being used primarily for ongoing debate/argument/trolling
> purposes could live indefinitely, generating hundreds, or thousands,
> of messages, and changesets/PR's, and list churn, in the name of
> "making sure an issue is adequately discussed and resolved".
> 
> Even as individual trolls, marks, and sockpuppets were knocked down,
> new ones could pick up the mantle of "but we're discussing important
> things, here!", and continue the loop, only finally exhausting the
> suite of RFC mechanisms all of the trolls/marks/puppets finally gave
> up, or were someho0w being administratively prohibited from all future
> participation.
> 
> Which, if the PHP email lists were an endless trolling/argument/debate
> forum like twitter or reddit, would be completely appropriate.
> 
> This is all hypothetical, of course.
> 
> -Ronabop
> 

Thats a valid problem.
How is this currently handled for the case, the troll is not willing to
withdraw it?

-Flyingmana


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

Re: [PHP-DEV] Handling of withdrawn RFCs

[Ronald Chmara]

On Thu, Jan 21, 2016 at 12:59 PM, Peter Lind  wrote:
> On 21 January 2016 at 21:53, Ronald Chmara  wrote:
>> On Thu, Jan 21, 2016 at 12:33 PM, Flyingmana 
>> wrote:
>> > Is there any way to abuse the taking over of an withdrawn RFC?
Snip_>
>> An RFC being used primarily for ongoing debate/argument/trolling
>> purposes could live indefinitely, generating hundreds, or thousands,
>> of messages, and changesets/PR's, and list churn, in the name of
>> "making sure an issue is adequately discussed and resolved".
>> Even as individual trolls, marks, and sockpuppets were knocked down,
>> new ones could pick up the mantle of "but we're discussing important
>> things, here!", and continue the loop...
Snip_>
> This thread being about withdrawn/re-proposed RFCs, how is that comment
> relevant?

The relevance is in ways to "abuse the taking over of an withdrawn RFC".

> Seeing as anyone wanting to debate/argument/troll indefinitely can
> do so using their own RFC -

Creating a new RFC has a higher barrier to entry, requiring additional effort.

> or, for that matter, without an RFC.

I would suggest that random email trolling does not have the same
audience, impact, or formal trappings of a public RFC process.

-Ronabop

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

Re: [PHP-DEV] Handling of withdrawn RFCs

[Peter Lind]

On 21 January 2016 at 22:24, Ronald Chmara  wrote:

> On Thu, Jan 21, 2016 at 12:59 PM, Peter Lind 
> wrote:
> > On 21 January 2016 at 21:53, Ronald Chmara  wrote:
> >> On Thu, Jan 21, 2016 at 12:33 PM, Flyingmana  >
> >> wrote:
> >> > Is there any way to abuse the taking over of an withdrawn RFC?
> Snip_>
> >> An RFC being used primarily for ongoing debate/argument/trolling
> >> purposes could live indefinitely, generating hundreds, or thousands,
> >> of messages, and changesets/PR's, and list churn, in the name of
> >> "making sure an issue is adequately discussed and resolved".
> >> Even as individual trolls, marks, and sockpuppets were knocked down,
> >> new ones could pick up the mantle of "but we're discussing important
> >> things, here!", and continue the loop...
> Snip_>
> > This thread being about withdrawn/re-proposed RFCs, how is that comment
> > relevant?
>
> The relevance is in ways to "abuse the taking over of an withdrawn RFC".
>
>
Ahhh good point, missed that.



> > Seeing as anyone wanting to debate/argument/troll indefinitely can
> > do so using their own RFC -
>
> Creating a new RFC has a higher barrier to entry, requiring additional
> effort.
>
>
If your aim is to clutter the mailing list indefinitely, that's really not
going to get in your way.



> > or, for that matter, without an RFC.
>
> I would suggest that random email trolling does not have the same
> audience, impact, or formal trappings of a public RFC process.
>
>
Random email trolling, no. But then again, random email trolling is not
really what we're talking about, is it?
Plus, it's a mailing list, not a forum. The default is that you follow
every thread, and have to actively mute them. Email trolling by splitting
off of threads would actually be more effective than keeping to one RFC
thread - not less effective.

Regards
Peter


-- 

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

Re: [PHP-DEV] PHP 7.0.3 RC1 is available for testing - **** BC break ***

[Yasuo Ohgaki]

Hi Remi and Stas,

Thank you for head up.
I'll address this today.
--
Yasuo Ohgaki
yohg...@ohgaki.net


On Fri, Jan 22, 2016 at 3:44 AM, Stanislav Malyshev  wrote:
> Hi!
>
>> Fedora detected a BC break in 5.6.18RC1 and 7.0.3RC1 related to
>> session management.
>
> Looks like something to do with last session changes. Yasuo, could you
> take a look at it?
>
> --
> Stas Malyshev
> smalys...@gmail.com

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

[PHP-DEV] Re: [RFC Discussion] Precise Session Management

[Yasuo Ohgaki]

Hi all,

On Fri, Jan 22, 2016 at 10:19 AM, Yasuo Ohgaki  wrote:
>
> https://github.com/php/php-src/pull/1734
>
> Few things are missing still, but it's good enough to review basic features.

Please note that if you execute run-tests.php with this patch,
it causes failures on other branches/versions' session tests.

To remove these test errors, you can do

rm -f /tmp/sess_*
rm -f /tmp/u_sess*

This issue will be fixed by the time when patch is completed.

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] Severe safety fail in file access and stream filters

[Yasuo Ohgaki]

Hi Umberto,

On Thu, Jan 21, 2016 at 10:30 AM, Umberto Salsi  wrote:
> I recently discovered several failures in error detection involving
> file access, stream compression and source inclusion that may bring the
> program to process missing or invalid data (very severe safety bug) or
> simply crash without apparent reason. I reported all these issues with
> their test script trying to do as much as I can to really understand
> what happen here. I think it's the time for some real internal expert
> to take over these issues and kindly reply to the following questions:
>
> 1. Is there something very basic I'm missing? I'm doing something wrong?
>
> 2. If yes, what can I do to fix so that i/o errors can be detected?
>
> 3. If no, why i/o errors do not propagate through the engine, but are
>mostly ignored? and why the user's program does not get signaled
>about this, and keeps receiving empty strings or garbage instead?

Plain file stream reads data by php_stdiop_read()

http://lxr.php.net/xref/PHP_5_6/main/streams/plain_wrapper.c#338

As you can see there is no way to return errors from it. We need
errno like error handling for PHP streams to propagate errors as well
as more robust code for unexpected.

So answer for 3 is "we need volunteers" for improvement, I suppose.
Anyone?

--
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.0.3 RC1 is available for testing - **** BC break ***

[Yasuo Ohgaki]

Hi Stas,

On Fri, Jan 22, 2016 at 7:15 AM, Stanislav Malyshev  wrote:
>
>> We have 2 choices
>>  - Enforce new and correct behavior since it will not affect normal
>>operation. i.e. Actual production site
>>  - Restore old behavior for the time being. (For this option, I prefer
>>to restore only for PHP 5.6, but Ok for PHP 7.0 also. No for master)
>
> Since it breaks applications, the existing behavior must be restored for
> both 5.6 and 7.0, unless it can be fixed ASAP. For master, a note should
> be made in UPGRADING at least, but if it's substantial change that
> requires applications to change then RFC would be requires I think.

The cause is logic, so it cannot be fixed unless we use bad logic.
The fix will be included in my RFC (
https://wiki.php.net/rfc/precise_session_management ). BTW, it will
not break application, but break tests for edge cases.

I'll revert the patch if test result is good.
Waiting Remi's response.

Regards,

--
Yasuo Ohgakid
yohg...@ohgaki.net

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

Re: [PHP-DEV] Severe safety fail in file access and stream filters

[Yasuo Ohgaki]

Hi,

On Fri, Jan 22, 2016 at 1:03 PM, Yasuo Ohgaki  wrote:
> On Thu, Jan 21, 2016 at 10:30 AM, Umberto Salsi  wrote:
>> I recently discovered several failures in error detection involving
>> file access, stream compression and source inclusion that may bring the
>> program to process missing or invalid data (very severe safety bug) or
>> simply crash without apparent reason. I reported all these issues with
>> their test script trying to do as much as I can to really understand
>> what happen here. I think it's the time for some real internal expert
>> to take over these issues and kindly reply to the following questions:
>>
>> 1. Is there something very basic I'm missing? I'm doing something wrong?
>>
>> 2. If yes, what can I do to fix so that i/o errors can be detected?
>>
>> 3. If no, why i/o errors do not propagate through the engine, but are
>>mostly ignored? and why the user's program does not get signaled
>>about this, and keeps receiving empty strings or garbage instead?
>
> Plain file stream reads data by php_stdiop_read()
>
> http://lxr.php.net/xref/PHP_5_6/main/streams/plain_wrapper.c#338
>
> As you can see there is no way to return errors from it. We need
> errno like error handling for PHP streams to propagate errors as well
> as more robust code for unexpected.
>
> So answer for 3 is "we need volunteers" for improvement, I suppose.
> Anyone?

Since I replied, I'll write an implementation idea.

We may add "error" and "clear_error" stream ops in php_stream_ops.

/* operations on streams that are file-handles */
typedef struct _php_stream_ops  {
/* stdio like functions - these are mandatory! */
size_t (*write)(php_stream *stream, const char *buf, size_t count
TSRMLS_DC);
size_t (*read)(php_stream *stream, char *buf, size_t count TSRMLS_DC);
int(*close)(php_stream *stream, int close_handle TSRMLS_DC);
int(*flush)(php_stream *stream TSRMLS_DC);

const char *label; /* label for this ops structure */

/* these are optional */
int (*seek)(php_stream *stream, off_t offset, int whence, off_t
*newoffset TSRMLS_DC);
int (*cast)(php_stream *stream, int castas, void **ret TSRMLS_DC);
int (*stat)(php_stream *stream, php_stream_statbuf *ssb TSRMLS_DC);
int (*set_option)(php_stream *stream, int option, int value, void
*ptrparam TSRMLS_DC);
} php_stream_ops;

"error" adds whatever errors from stream to an array.
"clear_error" cleanups the array when stream is closed.
There should be an API to get errors in the array.

This is easy change. Difficult part is making codes more robust against
unexpected for all streams.

Regards,

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

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

[PHP-DEV] Help compiling PHP 5.5.31

[李昀陞]

Hi all, I tried to build PHP static mode that running on Android. I used
Android-ndk to cross compile.
I wanted to know about PHP's "android-configure" file like Node.js :
https://github.com/nodejs/node/blob/master/android-configure

I saw many references about crossing compile PHP for ARM and Android , like
this post :
http://stackoverflow.com/questions/19028072/building-android-app-for-running-php-and-mysql-on-android-tablet

Unfortunately, most of posts were not very detailed and I tried their steps
that It was not worked.
I want the PHP can provide official android-configure file or guide about
crossing compile PHP on Android. Thanks for help.
-- 
李昀陞 敬啟

Re: [PHP-DEV] PDO Close Connection

[Rowan Collins]

Gabriel Zerbib wrote on 21/01/2016 14:32:

Hi, list!

This is my first email to this mailing list, so please pardon me for misuse
of the traditions you may have here (formatting, phrasing, etc.).


Welcome! :)


Maybe this has been discussed in depth earlier, but: I want to ask if there
is an explicit reason for not giving a "close" instance method in the PDO
class.


I think the main problem with a close method on something that 
represents a resource like a PDO connection object is how the object 
should behave *after* it has been closed. That is, what should the 
following code do?


$pdo = new PDO($dsn);
$pdo->closeConnection();
$pdo->query('Select 1 as test');

The object needs to track the fact that it is in a closed state, and do 
something - maybe throw a ConnectionAlreadyClosedException? But then 
what should the calling code do about that? If you have many objects 
with reference to that PDO object, then any one of them could "close" 
it, and any one could then try to execute a query. If you're not 
careful, your closeConnection() method could become a 
killScriptNextTimeAQueryIsAttempted() method.


If what you are actually doing is putting the connection to sleep, to be 
"woken up" later, you need *all* the references to the object to have 
the ability to "wake it up", because if you just create a new 
connection, you've somehow got to propagate it to all the same places 
you'd have to unset() in the current implementation. So that means the 
close() method needs to be accompanied by a reopen() method, which means 
saving the DSN and credentials, and any initialisation calls you want to 
make at the beginning of the connection (setting encoding, etc)...




In an application made of dependency injection, closures and many levels of
function calls split over many files, it is virtually impossible to keep
reference counting mentally, and you mostly end up never knowing what other
component of the application still retains a reference to the PDO object.


One solution to this is to create a wrapper around PDO, which is the 
only thing allowed to have a direct reference to the PDO object itself. 
To this object, you can add a close() method to your wrapper, and maybe 
isOpen(). If you save the DSN as well as the connection object, you can 
then go further and have reopen(), openOnNextQuery() (lazy-loading), or 
have your implementation of query() silently ensure that a connection is 
open. You could have a hook that fires on connection / disconnection to 
notify other objects, a list of SQL calls to run on connection, etc. etc.


That's not to say that a simple implementation of just 
close-and-fire-exception would be a horrible idea in PDO, but having one 
object which represents an open connection, and a separate one which 
represents a *potential* connection (maybe open, maybe closed, maybe 
not-open-yet) is a useful abstraction, and doesn't need anything in PDO 
itself.


Regards,
--
Rowan Collins
[IMSoP]

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