Re: [PHP-DEV] Is it fair that people with no karma can vote on RFCs?

[Pierre Joye]

On Tue, Sep 23, 2014 at 4:21 AM, Johannes Schlüter
 wrote:

> The approach I have in mind is going back to a consensus model by
> default, allowing truly everybody to participate and giving the
> opportunity to call for a vote if consensus can't be reached.

It never worked in the last decade+, what makes you think it will work
all of a sudden?

All I see is some being afraid to loose control while all RFCs show
that it is by far not the case. The active core devs did not loose
control and we reached many consensuses. We have a couple of issues
but the roots of them are very clear. All is all there is no reason to
go back in a very bad time for php.

> Given our
> social diversity I however think that this hardly works out as there
> always will be somebody calling for a vote ... obvious consequence would
> be a quorum for calling for a vote .. wich ends up in even more
> bureaucracy hell.

There is no bureaucracy hell but an end to endless discussions,
pressures, and other nonconstructive behaviors. The recent RFC events
about starting, ending, counting are unlucky but easily fixable.

Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org

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

[PHP-DEV] Re: Re: OpenSSL bug in 5.4.33 and 5.5.17

[Daniel Lowrey]

>> Hi,
>>
>> That's a bad thing we need to fix ASAP.
>>
>> I think for 5.6.1 we'll revert it , if not, we'll need an RC2, which
>> is something we usually don't do (but as this could involve security,
>> we may do it).
>> The fix can be merged to 5.5.18RC1, next week, to have an RC cycle if
>> not part of a 5.6.1RC2 (tag is tomorrow)
>>
>> 5.6 and 5.5 actually overlap in the release weeks. 5.6 is planned on
>> odd weeks whereas 5.5 is on even weeks.
>>
>> Waiting for Ferenc's advice anyway.
>>
>> Julien.P
>
>I have no issues with reverting at this point as that's the best route to
>get stable releases back on track. I thought I had fixed some really old
>bugs with those commits but the medicine turned out to be worse than the
>disease. My apologies again for letting those problems sneak into releases
>:/

I've got the necessary fixes lined up at this point, I just need to know
how you guys would prefer to proceed on this.

I can commit the relevant changes to 5.4, 5.5 and 5.6 and double-check with
RMs to ensure they make it into this next set of releases or we can revert
the previous commits and forget about the bug fixes altogether.

Just let me know which you prefer. Thanks.

Re: [PHP-DEV] Is it fair that people with no karma can vote on RFCs?

[Kris Craig]

On Mon, Sep 22, 2014 at 7:21 PM, Johannes Schlüter 
wrote:

> Hi,
>
> On Mon, 2014-09-22 at 14:36 -0700, Kris Craig wrote:
>
> > > Slightly provocative:  Why should I be forced to maintain code by
> > people who
> > > don't want to maintain it themselves?
> >
> > Nobody is forcing you to do anything.  You choose to contribute to PHP
> > in the manner in which you do, just as other people choose to
> > contribute in different, sometimes less obvious, ways.
>
> Right, nobody can truely enforce me doing something, still I gave some
> form of promise/commitment to less so since 5.3 reached EOL but still
> this might require me to do something.
>
> > Probably even due to votes by people
> > > about whom I don't know anything? Mind that most maintenance work by
> > > most contributors happens in free time on a voluntarily base.
> > >
> > > And no open source doesn't mean democracy as governing model.
> >
> > It can.  Every project is governed differently.
>
> Well democracy can mean so many things - in ancient Greece, the origin
> of democracy, only the men of a social group had a vote. Even in
> Switzerland, which is famous for its direct democracy, women weren't
> allowed to vote till 1971 (in the canton Appenzell Innerrhoden even only
> till 1990 for municipal issues) in others the voting power is unequally
> distributed (see i.e. the EU parliament where larger countries have less
> MEPs than smaller ones and different voting system's in different
> countries give different weight to citizens of different countries)
>
> Anyways this is a way different debate.
>

Fair enough.


>
> > Winston Churchill once famously said that democracy is the worst form
> > of government, except all the others that have been tried.
>
> While this depends on your view on what is good - Louis XIV of France
> was quite happy with his, I assume. But government of a society is
> different from governance of a software project. One case leads to a
> revolution, the other to a fork.
>

Also fair enough.


>
> > The
> > > democratic part is that people who don't like it can fork the
> > project and
> > > eventually receive a higher traction.
> >
> > And then we can have dozens of competing PHP codebases floating
> > around.
>
> That's were the social aspect comes back in - even people without a
> formal vote have ability to impact the project.
>

But that's assuming the threat of fork will be enough, thereby keeping
forks to a minimum.  I'm not sure I can concur with that assumption.


>
> > The problem with that model is that history has consistently shown
> > that those in power may listen, but will ultimately just do what they
> > want, anyway.
>
> If those with power will "ultimately just do what they want, anyway" the
> official form of governance doesn't matter at all. Thanks for agreeing
> to that :-D
>

I think you misunderstood.  Ignoring vote results derived from a
legitimized process that was agreed to is much more difficult that ignoring
a request made by some person without karma, with or without the threat of
a fork.


>
> But as this went to a path through European history let me reiterate and
> clarify what I said in a different post in this thread: The strict
> dependence on a vote impacts the constructive feedback for proposers
> negatively. It also provides no feedbackloop for leading to constructive
> critic being ignored, it becomes less clear whether voters were aware of
> that. It also makes simple contributions hard, adding quite some
> transactional cost for small improvements by newcomers. (then again here
> is no clear and objective measure what "small" includes) This is
> demotivating for all sides.
>

I wouldn't be against modifying the voting process to require everyone to
state a brief reason for their vote in order for it to be counted.  The
current table could be modified to add a text column easily enough, I'm
sure, and the results could display the reason next to each vote in the
row.  I think that would at least help mitigate the concerns you're raising
here.


>
> The approach I have in mind is going back to a consensus model by
> default, allowing truly everybody to participate and giving the
> opportunity to call for a vote if consensus can't be reached. Given our
> social diversity I however think that this hardly works out as there
> always will be somebody calling for a vote ... obvious consequence would
> be a quorum for calling for a vote .. wich ends up in even more
> bureaucracy hell.
>

I've noticed that minor changes are already made all the time without a
vote being called and I don't have any problem with that, nor am I aware of
anyone else who does.  Perhaps we could clarify exactly when a vote is
required and when it's not, but since that does not appear to have been an
issue thus far, it would probably just be a solution in search of a problem.


> >
> > I feel it's also worth reminding everyone that VCS accounts generally
> > aren't given away like candy.  Most people who have that 

Re: [PHP-DEV] [RFC] Change checkdnsrr() $type argument behavior

[Sanford Whiteman]

> What would happen is it'd throw an E_DEPRECATED for at least the remainder
> of 5.x, then throw the usual E_WARNING for a missing argument starting in
> 7.x with no default.

Sounds OK to me now that I've noticed this:

https://bugs.php.net/bug.php?id=68081

Pretty sure that's a sane report, and it's enough to make me say
checkdnsrr() doesn't work now at all.

-- S.

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

Re: [PHP-DEV] [RFC] Change checkdnsrr() $type argument behavior

[Kris Craig]

On Mon, Sep 22, 2014 at 8:09 PM, Sanford Whiteman 
wrote:

> Hi Kris,
>
> On a broad level, your RFC asserts that checkdnsrr() is used to
> determine "whether or not a hostname exists," but you don't actually
> define "exists."  It seems to me you're glossing over the fact that
> "existence" is application-specific and doesn't add up to one single
> RR type or set of types.
>
> For example, when setting up a web hosting account (www.example.com),
> or, say, an organization-wide account for a web app
> (sharepoint.example.com) when example.com's DNS is managed by the
> tenant, we may want to determine whether the hostname "exists": "Is
> there an A or CNAME RR in the DNS for that hostname?"  [1] Of course,
> that A/CNAME needs to eventually point to your servers to be useful,
> but with this barebones, non-professional-grade check, we could at
> least tell the tenant they pre-created a record successfully. (Or,
> contrariwise, we could tell them the hostname already exists, so it
> may already be used by one of their other apps.) Note if checkdnsrr()
> did an ANY query, `true` would be meaningless in this context.  It
> would be an instant false-positive if there were only an SOA and a
> coupla NSs.
>
> But when setting up a new user for a different kind of app, we may use
> their e-mail address (j...@example.com) as their username and we'll
> most certainly use it for a verification e-mail.  Here, we might
> quick-check whether example.com "exists" in the mail context, giving a
> reasonable expectation that it will accept mail (maybe not ours, of
> course!): "Is there an MX, A, or CNAME RR in the DNS for that
> hostname?" [2] This is a different, perfectly valid way that a
> hostname may "exist."  Note again if checkdnsrr() defaulted to ANY,
> `true` would be meaningless/misleading. And also note (I'll explore
> this again below) that an MX record is not required to accept mail.
> You can't decide that a domain is SMTP-nonexistent just because
> there's no MX.  Users will just be angry if they are already receiving
> mail and you tell them their address hard-failed your preflight check:
> warn them, perhaps, but leave it up to the SMTP layer to make those
> hard decisions.
>
> For another example, if you run a purpose-built DNS management app,
> you may want to know if a domain is in the DNS at all: "Are there
> simply SOA and NS RRs in the DNS?" This is another completely valid
> meaning.  You wouldn't want to check for CNAME, MX, or A here, since
> none of them are mandatory. True, you could in theory waste your
> resources on an ANY query for this one.  But it is not a compelling
> reason to have ANY be the default.
>
> For yet another example, if I'm building an SPF test tool I want to
> check if TXT or SPF/99 records exist for the hostname.  I don't care
> if the hostname has CNAME, MX, or A -- in fact, a hostname w/an SPF
> record solely to discourage Joe Jobs doesn't need to prove its
> existence in any other way.
>
> I mean, that's the thing about DNS. It serves tens of different
> purposes. It's not possible to assume what people are looking for when
> they build a specialized PHP app.  It could very well be that an app
> doesn't ever test for existence of A/CNAME, but only existence of SRV
> records. Or only PTRs.
>
> On one note I fully agree.  The defaulting to MX sucks.  But as others
> have pointed out it's a BC break to try to manipulate the arg list at
> this point in time.


I agree that it would be a BC, but I believe it would be a very minor one,
as I doubt very many people are relying on the current default behavior.
This minor level of BC would not be inappropriate for a major version
increment, as it's expected that there will be at least some BC there.

Based on your comments relating to DNS in general, it sounds like
defaulting to "ANY" wouldn't be much better than the current default.  I'm
beginning to lean heavily towards removing the second voting option and
limiting the scope of the RFC to just making the second argument required
for this reason.  What would happen is it'd throw an E_DEPRECATED for at
least the remainder of 5.x, then throw the usual E_WARNING for a missing
argument starting in 7.x with no default.

It has been my observation that a number of good ideas (and fixes to bad
ideas) have been set aside over fears of BC breakage.  While I agree
there's certainly a place for such caution, refusing to ever allow any BC
for such improvements even in major version increments essentially ties our
hands together and prevents the language from evolving past some of its
negative aspects.  BC is, by its very nature, a short-term concern.  I
doubt anybody is experiencing any problems caused by any BC that occurred
between PHP 3 and PHP 4, for example.  That's why I think major version
increments are the ideal time to implement more long-term objectives that
may carry a marginal short-term BC cost.  Given that just about everyone
here agrees that the current behavior is more or l

Re: [PHP-DEV] [RFC] Change checkdnsrr() $type argument behavior

[Sanford Whiteman]

Hi Kris,

On a broad level, your RFC asserts that checkdnsrr() is used to
determine "whether or not a hostname exists," but you don't actually
define "exists."  It seems to me you're glossing over the fact that
"existence" is application-specific and doesn't add up to one single
RR type or set of types.

For example, when setting up a web hosting account (www.example.com),
or, say, an organization-wide account for a web app
(sharepoint.example.com) when example.com's DNS is managed by the
tenant, we may want to determine whether the hostname "exists": "Is
there an A or CNAME RR in the DNS for that hostname?"  [1] Of course,
that A/CNAME needs to eventually point to your servers to be useful,
but with this barebones, non-professional-grade check, we could at
least tell the tenant they pre-created a record successfully. (Or,
contrariwise, we could tell them the hostname already exists, so it
may already be used by one of their other apps.) Note if checkdnsrr()
did an ANY query, `true` would be meaningless in this context.  It
would be an instant false-positive if there were only an SOA and a
coupla NSs.

But when setting up a new user for a different kind of app, we may use
their e-mail address (j...@example.com) as their username and we'll
most certainly use it for a verification e-mail.  Here, we might
quick-check whether example.com "exists" in the mail context, giving a
reasonable expectation that it will accept mail (maybe not ours, of
course!): "Is there an MX, A, or CNAME RR in the DNS for that
hostname?" [2] This is a different, perfectly valid way that a
hostname may "exist."  Note again if checkdnsrr() defaulted to ANY,
`true` would be meaningless/misleading. And also note (I'll explore
this again below) that an MX record is not required to accept mail.
You can't decide that a domain is SMTP-nonexistent just because
there's no MX.  Users will just be angry if they are already receiving
mail and you tell them their address hard-failed your preflight check:
warn them, perhaps, but leave it up to the SMTP layer to make those
hard decisions.

For another example, if you run a purpose-built DNS management app,
you may want to know if a domain is in the DNS at all: "Are there
simply SOA and NS RRs in the DNS?" This is another completely valid
meaning.  You wouldn't want to check for CNAME, MX, or A here, since
none of them are mandatory. True, you could in theory waste your
resources on an ANY query for this one.  But it is not a compelling
reason to have ANY be the default.

For yet another example, if I'm building an SPF test tool I want to
check if TXT or SPF/99 records exist for the hostname.  I don't care
if the hostname has CNAME, MX, or A -- in fact, a hostname w/an SPF
record solely to discourage Joe Jobs doesn't need to prove its
existence in any other way.

I mean, that's the thing about DNS. It serves tens of different
purposes. It's not possible to assume what people are looking for when
they build a specialized PHP app.  It could very well be that an app
doesn't ever test for existence of A/CNAME, but only existence of SRV
records. Or only PTRs.

On one note I fully agree.  The defaulting to MX sucks.  But as others
have pointed out it's a BC break to try to manipulate the arg list at
this point in time.  I think it would be good, maybe, to update the
docs with something like (though less clumsy): "This function's
default behavior is to verify the existence of MX records for a
hostname. MXs prove the domain owner's intent to receive mail.
However, a result of `false` does not mean a domain *cannot* receive
mail, as MXs are not mandatory."  Perhaps try to condition people to
be more aware of what they're looking up and why.  As someone else
said in the original thread, it's not too much to ask that PHP users
who decide to use DNS functions know what they're looking up.

Oh, and I also just caught a bug in the default behavior anyway.
Gonna log that now!

-- S.


[1] Here and elsewhere "A" means "A or ," although as of late 2014
the IPV6 variant isn't sufficient to establish "existence" on the
public 'Net.
[2] I'm deliberately setting aside the vario us CNAME interactions
with MX records, which may result in successful mail delivery in many,
but not all, permutations: it may be safer to consider such setups
broken, as long as you let the user confirm "Yes, I vouch for my
domain's setup/existence/operation even though you found problems."

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

Re: [PHP-DEV] Is it fair that people with no karma can vote on RFCs?

[Johannes Schlüter]

Hi,

On Mon, 2014-09-22 at 14:36 -0700, Kris Craig wrote:

> > Slightly provocative:  Why should I be forced to maintain code by
> people who
> > don't want to maintain it themselves?
> 
> Nobody is forcing you to do anything.  You choose to contribute to PHP
> in the manner in which you do, just as other people choose to
> contribute in different, sometimes less obvious, ways.

Right, nobody can truely enforce me doing something, still I gave some
form of promise/commitment to less so since 5.3 reached EOL but still
this might require me to do something.

> Probably even due to votes by people
> > about whom I don't know anything? Mind that most maintenance work by
> > most contributors happens in free time on a voluntarily base.
> >
> > And no open source doesn't mean democracy as governing model.
> 
> It can.  Every project is governed differently.

Well democracy can mean so many things - in ancient Greece, the origin
of democracy, only the men of a social group had a vote. Even in
Switzerland, which is famous for its direct democracy, women weren't
allowed to vote till 1971 (in the canton Appenzell Innerrhoden even only
till 1990 for municipal issues) in others the voting power is unequally
distributed (see i.e. the EU parliament where larger countries have less
MEPs than smaller ones and different voting system's in different
countries give different weight to citizens of different countries)

Anyways this is a way different debate.

> Winston Churchill once famously said that democracy is the worst form
> of government, except all the others that have been tried.

While this depends on your view on what is good - Louis XIV of France
was quite happy with his, I assume. But government of a society is
different from governance of a software project. One case leads to a
revolution, the other to a fork.

> The
> > democratic part is that people who don't like it can fork the
> project and
> > eventually receive a higher traction.
> 
> And then we can have dozens of competing PHP codebases floating
> around.  

That's were the social aspect comes back in - even people without a
formal vote have ability to impact the project.

> The problem with that model is that history has consistently shown
> that those in power may listen, but will ultimately just do what they
> want, anyway.

If those with power will "ultimately just do what they want, anyway" the
official form of governance doesn't matter at all. Thanks for agreeing
to that :-D

But as this went to a path through European history let me reiterate and
clarify what I said in a different post in this thread: The strict
dependence on a vote impacts the constructive feedback for proposers
negatively. It also provides no feedbackloop for leading to constructive
critic being ignored, it becomes less clear whether voters were aware of
that. It also makes simple contributions hard, adding quite some
transactional cost for small improvements by newcomers. (then again here
is no clear and objective measure what "small" includes) This is
demotivating for all sides.

The approach I have in mind is going back to a consensus model by
default, allowing truly everybody to participate and giving the
opportunity to call for a vote if consensus can't be reached. Given our
social diversity I however think that this hardly works out as there
always will be somebody calling for a vote ... obvious consequence would
be a quorum for calling for a vote .. wich ends up in even more
bureaucracy hell.
> 
> I feel it's also worth reminding everyone that VCS accounts generally
> aren't given away like candy.  Most people who have that access have
> done something or another to earn it.

It depends on the time of day and position of the stars, sometimes they
are thrown on people unless they run really fast, sometimes nobody looks
after requests ... :)

johannes
> 



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

Re: [PHP-DEV] Improve PHP 7 serialization

[Pierre Joye]

On Sep 23, 2014 1:23 AM, "Park Framework"  wrote:
>
> PHP serialization is slowest in PHP Session, clients NoSQL, ...
> I would like to have in PHP 7, a new serialization algorithm or custom
> handler to serialize.

The latter is already possible and there are many good extensions doing
that. Igbinary f.e.

> My opinion is that the best choice is to use msgpack, it is
> +110% faster
> -30% data size
>
> HHVM discussed this issue, but all boils down to backward compatibility
with PHP
> https://github.com/facebook/hhvm/issues/2654
>
> What do you think about this, maybe it's time to change the old
> algorithm serialization, on something better?
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

[PHP-DEV] Improve PHP 7 serialization

[Park Framework]

PHP serialization is slowest in PHP Session, clients NoSQL, ...
I would like to have in PHP 7, a new serialization algorithm or custom
handler to serialize.

My opinion is that the best choice is to use msgpack, it is
+110% faster
-30% data size

HHVM discussed this issue, but all boils down to backward compatibility with PHP
https://github.com/facebook/hhvm/issues/2654

What do you think about this, maybe it's time to change the old
algorithm serialization, on something better?

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

Re: [PHP-DEV] [VOTE][RFC] Scalar Type Hinting with Cast

[Pierre Joye]

On Sep 22, 2014 11:06 PM, "Stas Malyshev"  wrote:
>
> Hi!
>
> > - One about having scalar typed arguements, hinted or not, simple
> > yes/no, so we at least agree on having the feature
>
> I'm not sure how that would work. We agree on having what feature?
> Having coercive typing and having strict typing are two different
> options, working in different way and implying different coding
> approaches. And then there's also a third option which is a "compromise"
> approach where it is sometimes strict and sometimes not depending on a
> matrix of choices, and different matrices would work in different way.
> If I agree, for example, that coercive model is helpful - that doesn't
> mean I want complete strict typing, and I certainly would prefer none
> for now - in hope I would succeed convincing the majority in the future
> in the merits of coercive typing approach - than having strict model
> implemented now and closing the door for the coercive one forever. So I
> don't see how "at least agree" without specifying what we agreeing on
> works out.
>
> > To be more clear: We must get a decision here. I am convinced that
> > this is a top requested feature, since very long. Delay it forever
>
> Is there any data to support this conviction that this is not merely
> requested now and then, but it is a *top* requested feature since very
> long? Note that none of the languages most close to PHP have it.

Most?

Python has it, java too, ruby and perl not. We can continue to list those
having them or not, not sure that brings much to this discussion.


> Also, I did a poll one on stackoverflow:
>
>
http://programmers.stackexchange.com/questions/27564/what-features-would-you-like-to-have-in-php
>
> and it's not on top at all, though it is among the requested ones.
> However, having no consensus on it, saying "let's get together and make
> something" does not look like a good idea to me, because there are
> opportunity costs to prematurely having "something" that is not
> satisfactory.

Everyone I asked wants it, be at conferences, UGs, or devolopers of one of
the top tools or framework out there. There was also
http://www.php-vote.com/browse/latest showing in the top requests.

In any case, this endless discussion leads nowhere and we are not going to
have anything done using such debates and arguing.

Cheers,

--

Pierre

[PHP-DEV] [RFC] ZPP Failure On Overflow

[Andrea Faulds]

Good evening again,

Here’s a new RFC: https://wiki.php.net/rfc/zpp_fail_on_overflow

Thoughts appreciated, as is help with the patch, though I can probably manage 
on my own.

Thanks!
--
Andrea Faulds
http://ajf.me/





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

Re: [PHP-DEV] Is it fair that people with no karma can vote on RFCs?

[Kris Craig]

On Sep 22, 2014 8:39 AM, "Johannes Schlüter"  wrote:
>
>
>
> On September 22, 2014 4:21:29 PM CEST, Rafael Kassner 
wrote:
> >IMHO, denying non-karma people to vote is like to making PHP a
> >company's
> >product, or, in another words, "you use what we built and shut up",
> >because
> >only listening people won't allow to accept/deny a particular RFC, only
> >votes do. People surely don't comment (myself included) why they are
> >choosing some particular option on a RFC, but they are making their
> >opinion
> >count, and I think this kind of "democracy power" shouldn't be voided.
>
> Slightly provocative:  Why should I be forced to maintain code by people
who
> don't want to maintain it themselves?

Nobody is forcing you to do anything.  You choose to contribute to PHP in
the manner in which you do, just as other people choose to contribute in
different, sometimes less obvious, ways.

Probably even due to votes by people
> about whom I don't know anything? Mind that most maintenance work by
> most contributors happens in free time on a voluntarily base.
>
> And no open source doesn't mean democracy as governing model.

It can.  Every project is governed differently.

Winston Churchill once famously said that democracy is the worst form of
government, except all the others that have been tried.

The
> democratic part is that people who don't like it can fork the project and
> eventually receive a higher traction.

And then we can have dozens of competing PHP codebases floating around.

But no, "one man one vote" and full
> equality doesn't work out. (i.e. if a modules primary maintainer vetos a
> change I have to mind that [which doesn't mean I have to agree in the
> end])
>
> >Using separated voting count isn't an option? Like only internal
> >changes
> >are voted only by people with karma and features/changes/small BC
> >breaks
> >that affects userland are allowed to anyone. This way I believe is easy
> >to
> >say if either internals and community agrees with the proposed change
> >and
> >community people are making their opinion count.
>
> There are no plans (and enough people who'd veto such plans) to close
> the mailing list. Everybody might state their opinion and we are happy to
> receive (constructive) feedback and ideas here. And yes, this can be a bit
> painful due to different forms of "trolling" but leads to better results
respecting
> more opinions than a yes/no vote.

The problem with that model is that history has consistently shown that
those in power may listen, but will ultimately just do what they want,
anyway.

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

I feel it's also worth reminding everyone that VCS accounts generally
aren't given away like candy.  Most people who have that access have done
something or another to earn it.

--Kris

Re: [PHP-DEV] Is it fair that people with no karma can vote on RFCs?

[Adam Harvey]

On 22 September 2014 04:32, Derick Rethans  wrote:
> On Sat, 20 Sep 2014, Andrea Faulds wrote:
>
>> Perhaps I’m being unfair and overthinking things, but I wonder if it
>> is really fair for people who have no karma, i.e. not contributors to
>> the documentation, extensions, php-src or anything else, to have the
>> ability to vote on RFCs?
>>
>> I’d never suggest people without internals karma can’t vote. I think
>> doc and peck contributors are as valued as any other contributors.
>> However, people with no karma whatsoever (a blank people.php.net page)
>> voting irks me.
>
> I think people's votes should only count if they have karma to the
> section of the code that the RFC/feature/whatever relates to.

+1. I've said this plenty over the last couple of years, as IRC
regulars can attest to. Ultimately, people who actually know and
maintain the codebase should be making the final decisions.

Which is definitely not to say that we shouldn't be listening to
people outside the voting group — obviously, we should listen, and get
feedback. I just don't believe that the haziness of the current
process ("we might give you a voting account if you meet mostly
undefined criteria which no two people actually agree on, which then
allows you to provide a single tick with no feedback") encourages
that, and at some point we're going to end up with a feature being
committed that is going to cause major headaches for day to day
developers.

Adam

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

Re: [PHP-DEV] [VOTE][RFC] Scalar Type Hinting with Cast

[Stas Malyshev]

Hi!

> - One about having scalar typed arguements, hinted or not, simple
> yes/no, so we at least agree on having the feature

I'm not sure how that would work. We agree on having what feature?
Having coercive typing and having strict typing are two different
options, working in different way and implying different coding
approaches. And then there's also a third option which is a "compromise"
approach where it is sometimes strict and sometimes not depending on a
matrix of choices, and different matrices would work in different way.
If I agree, for example, that coercive model is helpful - that doesn't
mean I want complete strict typing, and I certainly would prefer none
for now - in hope I would succeed convincing the majority in the future
in the merits of coercive typing approach - than having strict model
implemented now and closing the door for the coercive one forever. So I
don't see how "at least agree" without specifying what we agreeing on
works out.

> To be more clear: We must get a decision here. I am convinced that
> this is a top requested feature, since very long. Delay it forever

Is there any data to support this conviction that this is not merely
requested now and then, but it is a *top* requested feature since very
long? Note that none of the languages most close to PHP have it.
Also, I did a poll one on stackoverflow:

http://programmers.stackexchange.com/questions/27564/what-features-would-you-like-to-have-in-php

and it's not on top at all, though it is among the requested ones.
However, having no consensus on it, saying "let's get together and make
something" does not look like a good idea to me, because there are
opportunity costs to prematurely having "something" that is not
satisfactory.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/

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

Re: [PHP-DEV] [VOTE][RFC] Integer Semantics

[Stas Malyshev]

Hi!

> I didn’t close it because the time suited me most. I made an honest
> mistake and closed it 22 or so hours early because I forgot I’d
> opened the vote at ~23:00 and not ~02:00. Unfortunately, I realised
> my mistake after merging the patch. This was definitely not
> intentional.

That's why we should not rush to merge changes on a vote when there are
significant objections. There's nothing that mandated this change to be
merged immediately after the voting closing, as far as I can see. Yes,
we do not want to make the process endless, but it's better to wait just
a bit and ensure everybody is satisfied or at least reasonably listened
to. Begging people off-list to retract the votes and then close it
earlier on a very marginal result definitely looks like gaming the
system, even if the intent was not to do that. But the intent is only
known to one person, and the actions can be seen by all, so I think it's
better to take extra care here. We want the voting to be means of
enhancing the consensus, not something that would leave people losing
the confidence in the whole process.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/

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

Re: [PHP-DEV] [VOTE][RFC] Integer Semantics

[Levi Morrison]

On Mon, Sep 22, 2014 at 10:09 PM, Pierre Joye  wrote:

>
> On Sep 22, 2014 10:05 PM, "Levi Morrison"  wrote:
>
> > I don't want to say anything else here, as technically this is thread
> hijacking (sorry Andrea) but I am very interested in collaborating with
> anyone who would like to try to improve the RFC process. Perhaps reply to
> me off-list if you are also interested.
>
> This is already a bad start to make this process more open or clear.
>
No, you simply failed to understand it. Collaboration in a smaller group
first, then open it up later. This catches a significant number of issues
before hitting the list, making the time on-list more valuable. I wish
*every* RFC was conducted in this fashion.

Re: [PHP-DEV] [VOTE][RFC] Integer Semantics

[Levi Morrison]

On Mon, Sep 22, 2014 at 3:37 PM, Pierre Joye  wrote:

> On Sep 22, 2014 3:31 PM, "Derick Rethans"  wrote:
> >
> > On Mon, 22 Sep 2014, Michael Wallner wrote:
> >
> > > On 2014-09-22 14:08, Andrea Faulds wrote:
> > > >
> > > > On 22 Sep 2014, at 12:06, Derick Rethans  wrote:
> > > >
> > > >> I would also like to point out that, just like a 8:8 vote is not a
> > > >> "50% majority", 16:8 is technically also not a two thirds
> > > >> *majority*. The RFC, like with many other important things is of
> > > >> course too vague on this.
> > >
> > > The "+1" is only for 50% majorities.
> > >
> > > >
> > > > An 8:8 vote is not a majority, no, but a 9:8 would be a 50%+1
> > > > majority.
> > > >
> > > > A 16:8 vote *is* a 2/3 majority.
> > >
> > > Yes, I think so, too.
> >
> > I disagree, but the main point was something else.
>
> Right, but what would be 2/3 of 24 votes for you then?
>
> > The "voting RFC" should be more clear on this. I don't think it is now.
> > It's a pretty vague RFC in the first place, and leaves way too much
> > open for interpretation.
>
> For? # of votes?
>

I have actually been working with several other people trying to come up
with smarter rules for the way we work with RFCs. Undoubtably, confusion
about what constitutes a "language change" is a huge issue. To be
completely honest, I would prefer that we require 2/3 on all RFCs. PHP is a
mature language; if we can't get 2/3 to agree on something it probably
isn't good for the whole of the PHP project.

I don't want to say anything else here, as technically this is thread
hijacking (sorry Andrea) but I am very interested in collaborating with
anyone who would like to try to improve the RFC process. Perhaps reply to
me off-list if you are also interested.

Re: [PHP-DEV] [VOTE][RFC] Integer Semantics

[Florian Margaine]

Hi,

Just a side remark: from an external point of view, it seems like you need
an application to handle the RFCs. An application with a strict business
logic, which leaves no ambiguity as to when and how an RFC should be valid.

The "what" is more ambiguous however, and I'm not sure as to how it should
be handled.

Regards,

*Florian Margaine*

On Mon, Sep 22, 2014 at 10:05 PM, Levi Morrison  wrote:

> On Mon, Sep 22, 2014 at 3:37 PM, Pierre Joye  wrote:
>
> > On Sep 22, 2014 3:31 PM, "Derick Rethans"  wrote:
> > >
> > > On Mon, 22 Sep 2014, Michael Wallner wrote:
> > >
> > > > On 2014-09-22 14:08, Andrea Faulds wrote:
> > > > >
> > > > > On 22 Sep 2014, at 12:06, Derick Rethans  wrote:
> > > > >
> > > > >> I would also like to point out that, just like a 8:8 vote is not a
> > > > >> "50% majority", 16:8 is technically also not a two thirds
> > > > >> *majority*. The RFC, like with many other important things is of
> > > > >> course too vague on this.
> > > >
> > > > The "+1" is only for 50% majorities.
> > > >
> > > > >
> > > > > An 8:8 vote is not a majority, no, but a 9:8 would be a 50%+1
> > > > > majority.
> > > > >
> > > > > A 16:8 vote *is* a 2/3 majority.
> > > >
> > > > Yes, I think so, too.
> > >
> > > I disagree, but the main point was something else.
> >
> > Right, but what would be 2/3 of 24 votes for you then?
> >
> > > The "voting RFC" should be more clear on this. I don't think it is now.
> > > It's a pretty vague RFC in the first place, and leaves way too much
> > > open for interpretation.
> >
> > For? # of votes?
> >
>
> I have actually been working with several other people trying to come up
> with smarter rules for the way we work with RFCs. Undoubtably, confusion
> about what constitutes a "language change" is a huge issue. To be
> completely honest, I would prefer that we require 2/3 on all RFCs. PHP is a
> mature language; if we can't get 2/3 to agree on something it probably
> isn't good for the whole of the PHP project.
>
> I don't want to say anything else here, as technically this is thread
> hijacking (sorry Andrea) but I am very interested in collaborating with
> anyone who would like to try to improve the RFC process. Perhaps reply to
> me off-list if you are also interested.
>

Re: [PHP-DEV] [VOTE][RFC] Integer Semantics

[Pierre Joye]

On Sep 22, 2014 10:05 PM, "Levi Morrison"  wrote:

> I don't want to say anything else here, as technically this is thread
hijacking (sorry Andrea) but I am very interested in collaborating with
anyone who would like to try to improve the RFC process. Perhaps reply to
me off-list if you are also interested.

This is already a bad start to make this process more open or clear.

Re: [PHP-DEV] The ABI and bug 68057

[Pierre Joye]

On Mon, Sep 22, 2014 at 8:48 PM, Bob Weinand  wrote:
> https://bugs.php.net/bug.php?id=68057
>
> is a regression introduced in PHP 5.6.
> So code which still worked with PHP 5.5 breaks in 5.6.
>
> The big issue is here, that the fix for this bug requires ABI breakage. 
> (changing an unsigned short into a zend_uint)
>
> I know that ABI compatibility is a pretty serious issue here, but it also 
> means that some perfectly valid PHP 5.5 code which is supposed to still work 
> on 5.6 will silently break.
> So, is it worth to break ABI or does it have to wait for 5.7 or the next 
> major?


Is the actual code used by the parser exposed? If yes it will be
somehow bad as ext maintainers relying on this will need two different
builds. I do not think there are many affected exts out there tho'. If
not, then it is easy :)

-- 
Pierre

@pierrejoye | http://www.libgd.org

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

RE: [PHP-DEV] Is it fair that people with no karma can vote on RFCs?

[Pierre Joye]

On Sep 22, 2014 8:56 PM, "Zeev Suraski"  wrote:

> account for people contributing docs and other types of submissions.  I'd
> also consider adding a requirement for contributing at least X commits
(say
> 20 or 50) so that someone who did a one-off or two-off patch won't have
the
> same vote as someone who contributed  hundreds or thousands of commits.  I
> believe this data can be easily pulled from git.

And let add a time since actual last commit too?

This is bad in so many ways...

RE: [PHP-DEV] Is it fair that people with no karma can vote on RFCs?

[Pierre Joye]

On Sep 22, 2014 8:56 PM, "Zeev Suraski"  wrote:

> Last, the 2nd sub-bullet of the 2nd bullet ("regular participant of
> internals discussions") is especially problematic - as it basically pulls
> the barrier to entry to nothing, and is the opposite of well-defined.
When
> we revise the Voting RFC, it should go IMHO.  Talk is cheap - the way to
get
> a vote with PHP is to contribute - be it with code, docs, testing,
> frameworks or apps.

To kill the FUD about totally random ppl being able to vote:

To my knowdlege, nobody fitting in what is describe in this last line ever
voted. If someone knows a case where it happened, let me know.

RE: [PHP-DEV] Is it fair that people with no karma can vote on RFCs?

[Zeev Suraski]

> -Original Message-
> From: Derick Rethans [mailto:der...@php.net]
> Sent: Monday, September 22, 2014 2:33 PM
> To: Andrea Faulds
> Cc: PHP internals
> Subject: Re: [PHP-DEV] Is it fair that people with no karma can vote on
> RFCs?
>
> I think people's votes should only count if they have karma to the section
> of
> the code that the RFC/feature/whatever relates to.

I agree with that, to a degree.  I think it depends on whether we're talking
about implementation RFCs or feature RFCs.

As I mentioned in the past, when the Voting RFC was written  - I never
envisioned it would be used for implementation decisions.  Maybe it was
short sighted, maybe not - but to me, it was obvious that implementation
would be up to the respective code owners, and not the full voter base.  So
yes, implementation issues that deal with the engine should be decided by
those who have engine karma.  Implementation decisions to the mysqli
extension should be up to those who contributed to this codebase, even if
there's just a handful of them.  And so on and so forth.  Johannes recent
comments about maintenance of code are a major reason behind this approach,
but it goes beyond fairness.  The contributors are the domain experts in the
respective implementations - it makes no sense to open this up to the voter
base at large.  You want to have a say?  By all means, work your way in and
contribute;  Once you do, you'd have a vote.  Until then, you have a voice
in internals, but not a vote.

The second group is trickier - and those are language features and other
types of votes.  The way we work today - where SVN yes/no is the only
question - was absolutely not the intent of the Voting RFC and thankfully,
it's also clearly not the language it contains.  The original RFC read the
following:

* People with php.net SVN accounts that have contributed code to PHP
* Representatives from the PHP community, that will be chosen by those with
php.net SVN accounts

Unfortunately, this was changed without me noticing it at the time, to the
following:
* People with php.net SVN accounts that have contributed code to PHP
* Representatives from the PHP community, that will be chosen by those with
php.net SVN accounts
  * Lead developers of PHP based projects (frameworks, cms, tools, etc.)
  * regular participant of internals discussions

The first bullet is the one this thread deals with so far.  It clearly
states that having an SVN account isn't enough - but that code contributions
to PHP are mandatory.  We should probably consider revising that to also
account for people contributing docs and other types of submissions.  I'd
also consider adding a requirement for contributing at least X commits (say
20 or 50) so that someone who did a one-off or two-off patch won't have the
same vote as someone who contributed  hundreds or thousands of commits.  I
believe this data can be easily pulled from git.

While we're at it, IMHO, the second bucket is open ended and must be much
more well defined.  I think we need a process where people from the
community can be nominated and voted on - either by people from the first
line, or by some sort of a public community poll.  Having 'elections' for
representatives from the community doesn't sound like a bad idea to me :)
Another option is to take the 1-2 top contributors of the 10-20 top PHP
projects on github.  That's probably a lot easier and would eliminate much
of the politics involved.

Last, the 2nd sub-bullet of the 2nd bullet ("regular participant of
internals discussions") is especially problematic - as it basically pulls
the barrier to entry to nothing, and is the opposite of well-defined.  When
we revise the Voting RFC, it should go IMHO.  Talk is cheap - the way to get
a vote with PHP is to contribute - be it with code, docs, testing,
frameworks or apps.

Zeev

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

[PHP-DEV] The ABI and bug 68057

[Bob Weinand]

https://bugs.php.net/bug.php?id=68057

is a regression introduced in PHP 5.6.
So code which still worked with PHP 5.5 breaks in 5.6.

The big issue is here, that the fix for this bug requires ABI breakage. 
(changing an unsigned short into a zend_uint)

I know that ABI compatibility is a pretty serious issue here, but it also means 
that some perfectly valid PHP 5.5 code which is supposed to still work on 5.6 
will silently break.
So, is it worth to break ABI or does it have to wait for 5.7 or the next major?

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

[PHP-DEV] VCS Account Request: fmargaine

[Florian Margaine]

Hi,

Having done a few PRs now, I\'d like to assign bugs to myself on 
bugs.php.net to avoid having several people working on the same one. For this, 
I need a php.net account :-)


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

Re: [PHP-DEV] Is it fair that people with no karma can vote on RFCs?

[Brian Moon]

On 9/20/14, 0:11 , Sara Golemon wrote:



On Sep 19, 2014, at 18:29, Andrea Faulds  wrote:
Perhaps I’m being unfair and overthinking things,

Yes, you are.


but I wonder if it is really fair for people who have no karma, i.e. not 
contributors to the documentation, extensions, php-src or anything else, to 
have the ability to vote on RFCs?

Yes, it is.

-Sara


Yes, What Sara said. I am the type of person that would be excluded. I 
contributed to PHP a lot 10 years ago. However, in all the SVN and GIT 
moving, all my karma has long since been removed. I vote in almost every 
RFC because I have a long history with PHP and care about where it is 
going. People with dead accounts and who don't care about PHP most 
likely don't vote.


Brian Moon
brianlm...@php.net

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

[PHP-DEV] Re: Re: OpenSSL bug in 5.4.33 and 5.5.17

[Daniel Lowrey]

> Hi,
>
> That's a bad thing we need to fix ASAP.
>
> I think for 5.6.1 we'll revert it , if not, we'll need an RC2, which
> is something we usually don't do (but as this could involve security,
> we may do it).
> The fix can be merged to 5.5.18RC1, next week, to have an RC cycle if
> not part of a 5.6.1RC2 (tag is tomorrow)
>
> 5.6 and 5.5 actually overlap in the release weeks. 5.6 is planned on
> odd weeks whereas 5.5 is on even weeks.
>
> Waiting for Ferenc's advice anyway.
>
> Julien.P

I have no issues with reverting at this point as that's the best route to
get stable releases back on track. I thought I had fixed some really old
bugs with those commits but the medicine turned out to be worse than the
disease. My apologies again for letting those problems sneak into releases
:/

Re: [PHP-DEV] Is it fair that people with no karma can vote on RFCs?

[Pierre Joye]

On Mon, Sep 22, 2014 at 5:38 PM, Johannes Schlüter
 wrote:

> Slightly provocative:  Why should I be forced to maintain code by people who
> don't want to maintain it themselves? Probably even due to votes by people
> about whom I don't know anything? Mind that most maintenance work by
> most contributors happens in free time on a voluntarily base.

The same applies to many new codes. Even more for my team as we have
to take care of many issues where only a few actually takes care of.


> And no open source doesn't mean democracy as governing model. The
> democratic part is that people who don't like it can fork the project and
> eventually receive a higher traction. But no, "one man one vote" and full
> equality doesn't work out. (i.e. if a modules primary maintainer vetos a
> change I have to mind that [which doesn't mean I have to agree in the
> end])

Primary maintainers doing only maintenance but not having actually
designed/implemented an extension fits in this description. That
sounds pretty awkward to me, for anything landing in the core. Landed
in the core? Dictartorship goes away.

>>Using separated voting count isn't an option? Like only internal
>>changes
>>are voted only by people with karma and features/changes/small BC
>>breaks
>>that affects userland are allowed to anyone. This way I believe is easy
>>to
>>say if either internals and community agrees with the proposed change
>>and
>>community people are making their opinion count.
>
> There are no plans (and enough people who'd veto such plans) to close
> the mailing list. Everybody might state their opinion and we are happy to
> receive (constructive) feedback and ideas here. And yes, this can be a bit
> painful due to different forms of "trolling" but leads to better results 
> respecting
> more opinions than a yes/no vote.

Never worked before and it will suddenly work? I am open to know how
one can make it works. Unless you mean to go back to individual
deciding everything for a given area or ext.


Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org

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

[PHP-DEV] Re: PHP 5.6 and default cipher list in OpenSSL

[Daniel Lowrey]

> Hi,
>
> Sorry to have not detect this problem at RFC time, but the new hardcoded
> cipher list, cause some trouble in Fedora.
>
> See: https://bugs.php.net/68074
> http://fedoraproject.org/wiki/Changes/CryptoPolicy
> https://fedoraproject.org/wiki/User:Nmav/CryptoPolicies
> https://wiki.php.net/rfc/improved-tls-defaults#default_ciphers
>
> And the simple patch
>
https://bugs.php.net/patch-display.php?bug_id=68074&patch=system-ciphers.patch&revision=latest
>
> If no objection, plan to apply this quite soon in 5.6+

This is sensible to me. It gives distros the ability to fine-tune crypto
ciphers in accordance with their own policies and legal requirements. This
has been an issue for RHEL at least in the past with regard to elliptic
curve ciphers. Adding the compile directive would protect users by default
with the new ciphers without causing problems for those adhering to
specific organization/institutional requirements.

[PHP-DEV] PHP 5.6 and default cipher list in OpenSSL

[Remi Collet]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

Sorry to have not detect this problem at RFC time, but the new hardcoded
cipher list, cause some trouble in Fedora.

See: https://bugs.php.net/68074
http://fedoraproject.org/wiki/Changes/CryptoPolicy
https://fedoraproject.org/wiki/User:Nmav/CryptoPolicies
https://wiki.php.net/rfc/improved-tls-defaults#default_ciphers

And the simple patch
https://bugs.php.net/patch-display.php?bug_id=68074&patch=system-ciphers.patch&revision=latest

If no objection, plan to apply this quite soon in 5.6+


Cheers,
Remi.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlQgR04ACgkQYUppBSnxahhXvQCgwtPYInzckq6ZoWunPK8hL2UY
Qd4AoNa7v50CBnLWcBRfhC9Zsl53/DVK
=nV+z
-END PGP SIGNATURE-

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

[PHP-DEV] PHP 5.6 and default cipher list in OpenSSL

[Remi Collet]

Hi,

Sorry to have not detect this problem at RFC time, but the new hardcoded
cipher list, cause some trouble in Fedora.

See: https://bugs.php.net/68074
http://fedoraproject.org/wiki/Changes/CryptoPolicy
https://fedoraproject.org/wiki/User:Nmav/CryptoPolicies
https://wiki.php.net/rfc/improved-tls-defaults#default_ciphers

And the simple patch
https://bugs.php.net/patch-display.php?bug_id=68074&patch=system-ciphers.patch&revision=latest

If no objection, plan to apply this quite soon in 5.6+


Cheers,
Remi.

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

Re: [PHP-DEV] Is it fair that people with no karma can vote on RFCs?

[Johannes Schlüter]

On September 22, 2014 4:21:29 PM CEST, Rafael Kassner  wrote:
>IMHO, denying non-karma people to vote is like to making PHP a
>company's
>product, or, in another words, "you use what we built and shut up",
>because
>only listening people won't allow to accept/deny a particular RFC, only
>votes do. People surely don't comment (myself included) why they are
>choosing some particular option on a RFC, but they are making their
>opinion
>count, and I think this kind of "democracy power" shouldn't be voided.

Slightly provocative:  Why should I be forced to maintain code by people who 
don't want to maintain it themselves? Probably even due to votes by people
about whom I don't know anything? Mind that most maintenance work by
most contributors happens in free time on a voluntarily base. 

And no open source doesn't mean democracy as governing model. The 
democratic part is that people who don't like it can fork the project and 
eventually receive a higher traction. But no, "one man one vote" and full 
equality doesn't work out. (i.e. if a modules primary maintainer vetos a 
change I have to mind that [which doesn't mean I have to agree in the 
end])

>Using separated voting count isn't an option? Like only internal
>changes
>are voted only by people with karma and features/changes/small BC
>breaks
>that affects userland are allowed to anyone. This way I believe is easy
>to
>say if either internals and community agrees with the proposed change
>and
>community people are making their opinion count.

There are no plans (and enough people who'd veto such plans) to close
the mailing list. Everybody might state their opinion and we are happy to
receive (constructive) feedback and ideas here. And yes, this can be a bit
painful due to different forms of "trolling" but leads to better results 
respecting
more opinions than a yes/no vote.

johannes

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

Re: [PHP-DEV] Re: OpenSSL bug in 5.4.33 and 5.5.17

[Julien Pauli]

On Fri, Sep 19, 2014 at 6:49 PM, Remi Collet  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Le 19/09/2014 18:25, Daniel Lowrey a écrit :
 In an effort to fix a very old (seven years old) DoS
 vulnerability involving encrypted streams I created a
 regression where feof() notifications on encrypted sockets are
 broken. This is present in both the most recent 5.4.33 and
 5.5.17 releases.
>>
>>> Can you please point us to the related commit... (which one cause
>>> the regression, which ones are useful)
>>
>> In 5.4.33 and 5.5.17 an immediate fix is to revert these commits:
>>
>> http://git.php.net/?p=php-src.git;a=commitdiff;h=6569db88081562f68a4f79e52cba83482bdf05fc
>>
>>
>> http://git.php.net/?p=php-src.git;a=commitdiff;h=372844918a318ad712e16f9ec636682424a65403
>>
>>
>> http://git.php.net/?p=php-src.git;a=commitdiff;h=32be79dcfa1bc5af8682d9f512da68c5b3e2cbf3
>>
>>  The last of these (32be79d) has already been fixed upstream by
>> f86b2193a483f56b0bd056570a0cdb57ebe66e2f but this change did not go
>> into 5.4.33 and 5.5.17. Any reverts should also consider f86b2193.
>>
>>> Does a revert of the first enough to get back to previous
>>> behavior?
>>
>> Yes, reverting the above commits above will fix any issues. I'm
>> awaiting word from someone associated with Horde to verify that the
>> previously linked patch (
>> https://bugs.php.net/patch-display.php?bug=41631&patch=bug41631.patch&revision=1411139621)
>>
>>
> resolves the issue. As long as that works as expected I can merge that and
>> everything should be resolved going forward.
>>
>
> After a quick check
>
> 6569db8 and 32be79d are in 5.4.33 / 5.5.17 / 5.6.1RC1
> f86b219 and 3728449 are in 5.6.1RC1 only
>
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlQcXrUACgkQYUppBSnxahgfigCfUYmoYXJJYC0JKmLi/tg+mo1r
> mwwAoNXbDpPsdrVfzFWUy4tuOssqR256
> =OUHp
> -END PGP SIGNATURE-
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>


Hi,

That's a bad thing we need to fix ASAP.

I think for 5.6.1 we'll revert it , if not, we'll need an RC2, which
is something we usually don't do (but as this could involve security,
we may do it).
The fix can be merged to 5.5.18RC1, next week, to have an RC cycle if
not part of a 5.6.1RC2 (tag is tomorrow)

5.6 and 5.5 actually overlap in the release weeks. 5.6 is planned on
odd weeks whereas 5.5 is on even weeks.

Waiting for Ferenc's advice anyway.

Julien.P

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

Re: [PHP-DEV] Is it fair that people with no karma can vote on RFCs?

[Rafael Kassner]

IMHO, denying non-karma people to vote is like to making PHP a company's
product, or, in another words, "you use what we built and shut up", because
only listening people won't allow to accept/deny a particular RFC, only
votes do. People surely don't comment (myself included) why they are
choosing some particular option on a RFC, but they are making their opinion
count, and I think this kind of "democracy power" shouldn't be voided.

Using separated voting count isn't an option? Like only internal changes
are voted only by people with karma and features/changes/small BC breaks
that affects userland are allowed to anyone. This way I believe is easy to
say if either internals and community agrees with the proposed change and
community people are making their opinion count.

On Mon, Sep 22, 2014 at 10:39 AM, Pierre Joye  wrote:

> On Sep 22, 2014 3:29 PM, "Derick Rethans"  wrote:
> >
> > On Mon, 22 Sep 2014, Andrey Andreev wrote:
> >
> > > On Mon, Sep 22, 2014 at 3:10 PM, Andrea Faulds  wrote:
> > > >
> > > > On 22 Sep 2014, at 12:32, Derick Rethans  wrote:
> > > >
> > > >> On Sat, 20 Sep 2014, Andrea Faulds wrote:
> > > >>
> > > >>> Perhaps I’m being unfair and overthinking things, but I wonder if
> > > >>> it is really fair for people who have no karma, i.e. not
> > > >>> contributors to the documentation, extensions, php-src or anything
> > > >>> else, to have the ability to vote on RFCs?
> > > >>>
> > > >>> I’d never suggest people without internals karma can’t vote. I
> > > >>> think doc and peck contributors are as valued as any other
> > > >>> contributors. However, people with no karma whatsoever (a blank
> > > >>> people.php.net page) voting irks me.
> > > >>
> > > >> I think people's votes should only count if they have karma to the
> > > >> section of the code that the RFC/feature/whatever relates to.
> > > >
> > > > Is that really fair? If we break BC, plenty of userland developers
> > > > might be affected and they should have a right to chime in.
> > >
> > > That would be quite unfair, not just because of BC breaks and/or
> > > userland developers' votes (there aren't many, afaik).
> > > Practically every language change would be decided by only a handful
> > > of people, while it should be important that many votes are gathered
> > > for important decisions.
> >
> > There is a big difference between votes, and voices. Voices should
> > definitely be listened too.
>
> We agree on listening. Only not on how we listen.
>
> > Derick
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
>

Re: [PHP-DEV] Is it fair that people with no karma can vote on RFCs?

[Pierre Joye]

On Sep 22, 2014 3:29 PM, "Derick Rethans"  wrote:
>
> On Mon, 22 Sep 2014, Andrey Andreev wrote:
>
> > On Mon, Sep 22, 2014 at 3:10 PM, Andrea Faulds  wrote:
> > >
> > > On 22 Sep 2014, at 12:32, Derick Rethans  wrote:
> > >
> > >> On Sat, 20 Sep 2014, Andrea Faulds wrote:
> > >>
> > >>> Perhaps I’m being unfair and overthinking things, but I wonder if
> > >>> it is really fair for people who have no karma, i.e. not
> > >>> contributors to the documentation, extensions, php-src or anything
> > >>> else, to have the ability to vote on RFCs?
> > >>>
> > >>> I’d never suggest people without internals karma can’t vote. I
> > >>> think doc and peck contributors are as valued as any other
> > >>> contributors. However, people with no karma whatsoever (a blank
> > >>> people.php.net page) voting irks me.
> > >>
> > >> I think people's votes should only count if they have karma to the
> > >> section of the code that the RFC/feature/whatever relates to.
> > >
> > > Is that really fair? If we break BC, plenty of userland developers
> > > might be affected and they should have a right to chime in.
> >
> > That would be quite unfair, not just because of BC breaks and/or
> > userland developers' votes (there aren't many, afaik).
> > Practically every language change would be decided by only a handful
> > of people, while it should be important that many votes are gathered
> > for important decisions.
>
> There is a big difference between votes, and voices. Voices should
> definitely be listened too.

We agree on listening. Only not on how we listen.

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

Re: [PHP-DEV] [VOTE][RFC] Integer Semantics

[Pierre Joye]

On Sep 22, 2014 3:31 PM, "Derick Rethans"  wrote:
>
> On Mon, 22 Sep 2014, Michael Wallner wrote:
>
> > On 2014-09-22 14:08, Andrea Faulds wrote:
> > >
> > > On 22 Sep 2014, at 12:06, Derick Rethans  wrote:
> > >
> > >> I would also like to point out that, just like a 8:8 vote is not a
> > >> "50% majority", 16:8 is technically also not a two thirds
> > >> *majority*. The RFC, like with many other important things is of
> > >> course too vague on this.
> >
> > The "+1" is only for 50% majorities.
> >
> > >
> > > An 8:8 vote is not a majority, no, but a 9:8 would be a 50%+1
> > > majority.
> > >
> > > A 16:8 vote *is* a 2/3 majority.
> >
> > Yes, I think so, too.
>
> I disagree, but the main point was something else.

Right, but what would be 2/3 of 24 votes for you then?

> The "voting RFC" should be more clear on this. I don't think it is now.
> It's a pretty vague RFC in the first place, and leaves way too much
> open for interpretation.

For? # of votes?

> cheers,
> Derick

Re: [PHP-DEV] [VOTE][RFC] Integer Semantics

[Derick Rethans]

On Mon, 22 Sep 2014, Michael Wallner wrote:

> On 2014-09-22 14:08, Andrea Faulds wrote:
> > 
> > On 22 Sep 2014, at 12:06, Derick Rethans  wrote:
> > 
> >> I would also like to point out that, just like a 8:8 vote is not a 
> >> "50% majority", 16:8 is technically also not a two thirds 
> >> *majority*. The RFC, like with many other important things is of 
> >> course too vague on this.
> 
> The "+1" is only for 50% majorities.
> 
> > 
> > An 8:8 vote is not a majority, no, but a 9:8 would be a 50%+1
> > majority.
> > 
> > A 16:8 vote *is* a 2/3 majority. 
> 
> Yes, I think so, too.

I disagree, but the main point was something else.

The "voting RFC" should be more clear on this. I don't think it is now. 
It's a pretty vague RFC in the first place, and leaves way too much 
open for interpretation.

cheers,
Derick

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

Re: [PHP-DEV] Is it fair that people with no karma can vote on RFCs?

[Derick Rethans]

On Mon, 22 Sep 2014, Andrey Andreev wrote:

> On Mon, Sep 22, 2014 at 3:10 PM, Andrea Faulds  wrote:
> >
> > On 22 Sep 2014, at 12:32, Derick Rethans  wrote:
> >
> >> On Sat, 20 Sep 2014, Andrea Faulds wrote:
> >>
> >>> Perhaps I’m being unfair and overthinking things, but I wonder if 
> >>> it is really fair for people who have no karma, i.e. not 
> >>> contributors to the documentation, extensions, php-src or anything 
> >>> else, to have the ability to vote on RFCs?
> >>>
> >>> I’d never suggest people without internals karma can’t vote. I 
> >>> think doc and peck contributors are as valued as any other 
> >>> contributors. However, people with no karma whatsoever (a blank 
> >>> people.php.net page) voting irks me.
> >>
> >> I think people's votes should only count if they have karma to the 
> >> section of the code that the RFC/feature/whatever relates to.
> >
> > Is that really fair? If we break BC, plenty of userland developers 
> > might be affected and they should have a right to chime in.
> 
> That would be quite unfair, not just because of BC breaks and/or
> userland developers' votes (there aren't many, afaik).
> Practically every language change would be decided by only a handful
> of people, while it should be important that many votes are gathered
> for important decisions.

There is a big difference between votes, and voices. Voices should 
definitely be listened too.

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

Re: [PHP-DEV] Is it fair that people with no karma can vote on RFCs?

[Derick Rethans]

On Mon, 22 Sep 2014, Andrea Faulds wrote:

> On 22 Sep 2014, at 12:32, Derick Rethans  wrote:
> 
> > On Sat, 20 Sep 2014, Andrea Faulds wrote:
> > 
> >> Perhaps I’m being unfair and overthinking things, but I wonder if it 
> >> is really fair for people who have no karma, i.e. not contributors to 
> >> the documentation, extensions, php-src or anything else, to have the 
> >> ability to vote on RFCs?
> >> 
> >> I’d never suggest people without internals karma can’t vote. I think 
> >> doc and peck contributors are as valued as any other contributors. 
> >> However, people with no karma whatsoever (a blank people.php.net page) 
> >> voting irks me.
> > 
> > I think people's votes should only count if they have karma to the 
> > section of the code that the RFC/feature/whatever relates to.
> 
> Is that really fair? If we break BC, plenty of userland developers 
> might be affected and they should have a right to chime in.

Breaking BC should never happen anyway.

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

Re: [PHP-DEV] [VOTE][RFC] Integer Semantics

[Michael Wallner]

On 2014-09-22 14:08, Andrea Faulds wrote:
> 
> On 22 Sep 2014, at 12:06, Derick Rethans  wrote:
> 
>> I would also like to point out that, just like a 8:8 vote is not a
>> "50% majority", 16:8 is technically also not a two thirds
>> *majority*. The RFC, like with many other important things is of
>> course too vague on this.

The "+1" is only for 50% majorities.

> 
> An 8:8 vote is not a majority, no, but a 9:8 would be a 50%+1
> majority.
> 
> A 16:8 vote *is* a 2/3 majority. 

Yes, I think so, too.



-- 
Regards,
Mike

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

Re: [PHP-DEV] Is it fair that people with no karma can vote on RFCs?

[Andrey Andreev]

On Mon, Sep 22, 2014 at 3:10 PM, Andrea Faulds  wrote:
>
> On 22 Sep 2014, at 12:32, Derick Rethans  wrote:
>
>> On Sat, 20 Sep 2014, Andrea Faulds wrote:
>>
>>> Perhaps I’m being unfair and overthinking things, but I wonder if it
>>> is really fair for people who have no karma, i.e. not contributors to
>>> the documentation, extensions, php-src or anything else, to have the
>>> ability to vote on RFCs?
>>>
>>> I’d never suggest people without internals karma can’t vote. I think
>>> doc and peck contributors are as valued as any other contributors.
>>> However, people with no karma whatsoever (a blank people.php.net page)
>>> voting irks me.
>>
>> I think people's votes should only count if they have karma to the
>> section of the code that the RFC/feature/whatever relates to.
>
> Is that really fair? If we break BC, plenty of userland developers might be 
> affected and they should have a right to chime in.

That would be quite unfair, not just because of BC breaks and/or
userland developers' votes (there aren't many, afaik).
Practically every language change would be decided by only a handful
of people, while it should be important that many votes are gathered
for important decisions.

Cheers,
Andrey.

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

Re: [PHP-DEV] Is it fair that people with no karma can vote on RFCs?

[Andrea Faulds]

On 22 Sep 2014, at 12:32, Derick Rethans  wrote:

> On Sat, 20 Sep 2014, Andrea Faulds wrote:
> 
>> Perhaps I’m being unfair and overthinking things, but I wonder if it 
>> is really fair for people who have no karma, i.e. not contributors to 
>> the documentation, extensions, php-src or anything else, to have the 
>> ability to vote on RFCs?
>> 
>> I’d never suggest people without internals karma can’t vote. I think 
>> doc and peck contributors are as valued as any other contributors. 
>> However, people with no karma whatsoever (a blank people.php.net page) 
>> voting irks me.
> 
> I think people's votes should only count if they have karma to the 
> section of the code that the RFC/feature/whatever relates to.

Is that really fair? If we break BC, plenty of userland developers might be 
affected and they should have a right to chime in.
--
Andrea Faulds
http://ajf.me/





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

Re: [PHP-DEV] [VOTE][RFC] Integer Semantics

[Andrea Faulds]

On 22 Sep 2014, at 12:06, Derick Rethans  wrote:

> I would also like to point out that, just like a 8:8 vote is not a "50% 
> majority", 16:8 is technically also not a two thirds *majority*. The 
> RFC, like with many other important things is of course too vague on 
> this.

An 8:8 vote is not a majority, no, but a 9:8 would be a 50%+1 majority.

A 16:8 vote *is* a 2/3 majority. 2/3 of people have voted in favour, with 1/3 
against. It’s a very narrow one, but so far I’m yet to see anyone say it should 
be 2/3+1 and not plain 2/3.

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





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

Re: [PHP-DEV] ext/date arguments handling

[Florian Margaine]

Hi Derick,

Thanks for your answer!

Indeed, I did plan on doing another PR for 5.6 while keeping ZEND_ARG_INFO.
I'll review your notes and take care of them.

Regards,

*Florian Margaine*

On Mon, Sep 22, 2014 at 1:29 PM, Derick Rethans  wrote:

> Hi Florian,
>
> On Sun, 21 Sep 2014, Florian Margaine wrote:
>
> > I specifically mean to ask @derick about this issue I'm having, since
> > he is the maintainer of ext/date.
> >
> > I wrote this pull request for the DateTimeZone::getOffset method to
> > accept a DateTimeInterface instead of a DateTime object:
> > https://github.com/php/php-src/pull/831
> >
> > Instead of using ZEND_ARG_INFO, I use ZEND_ARG_OBJ_INFO rather than
> > relying on zpp only. It makes the code consistent with the type
> > hinting errors that should arise, and also gives a correct reflection.
> >
> > However, the rest of the code in this extension uses ZEND_ARG_INFO,
> > only throwing warnings when the arguments are not of the right kind.
> >
> > Should I use ZEND_ARG_INFO and rely on zpp's warning, or should I use
> > ZEND_ARG_OBJ_INFO, and eventually translate the other methods to use
> > it too? This'd be out of this PR of course, but it makes sense to
> > streamline the methods of ext/date.
>
> I think it should use ZEND_ARG_OBJ_INFO. However, I am not sure whether
> we can do that in 5.x because of BC reasons. It's these tiny mistakes
> that are the larger BC problems. So I would suggest that you make a PR
> for 5.6 without ZEND_ARG_OBJ_INFO, and one for 7 with ZEND_ARG_OBJ_INFO.
>
> I think the patch looks mostly good too. I would recommend you squash
> the commits into a single commit though.
>
> cheers,
> Derick
>

Re: [PHP-DEV] Is it fair that people with no karma can vote on RFCs?

[Derick Rethans]

On Sat, 20 Sep 2014, Johannes Schlüter wrote:

> On Sat, 2014-09-20 at 03:16 +0100, Leigh wrote:
> > 
> > I think everyone with the ability to vote should have to communicate 
> > their reasons behind their yes/no publicly on this mailing list for 
> > it to be valid. If you cannot describe in your own words why a 
> > proposal should or should not be accepted, why should your opinion 
> > be valid?
> > 
> That's one of the reasons why I consider voting as default way wrong. 
> It might be a way to solve ties if a consensus can't be reached.

That's another good point, that I stand behind. I think f.e. the integer 
semantics RFC was contentious enough to warrant further discussion and 
see what could make other people to say "yes" as well. The current RFC 
process does not state anything about reflecting comments on the ML to 
have to be addressed before the RFC can even be put to vote. And I 
think, valid (technical) objects should be required to be addressed.

> It is unclear what a "no" means. Might be a related to the patch the 
> design, a misunderstanding or due to a critical issue ...  in the end 
> a vote creates "losers" with little feedback.
> 
> But well, I'm saying this from day one of the voting.

Yes. I am in that camp too.

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

Re: [PHP-DEV] Is it fair that people with no karma can vote on RFCs?

[Derick Rethans]

On Sat, 20 Sep 2014, Andrea Faulds wrote:

> Perhaps I’m being unfair and overthinking things, but I wonder if it 
> is really fair for people who have no karma, i.e. not contributors to 
> the documentation, extensions, php-src or anything else, to have the 
> ability to vote on RFCs?
> 
> I’d never suggest people without internals karma can’t vote. I think 
> doc and peck contributors are as valued as any other contributors. 
> However, people with no karma whatsoever (a blank people.php.net page) 
> voting irks me.

I think people's votes should only count if they have karma to the 
section of the code that the RFC/feature/whatever relates to.

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

Re: [PHP-DEV] [VOTE][RFC] Null Coalesce Operator

[Derick Rethans]

On Sat, 20 Sep 2014, Patrick Schaaf wrote:

> Am 20.09.2014 01:35 schrieb "Andrea Faulds" :
> >
> > https://wiki.php.net/rfc/isset_ternary#vote
> 
> Hi,
> 
> got a question after being bitten my the issue yesterday in the context of
> the "@yadda ?: 'default'" form yesterday:
> 
> What about yadda that results, at the moment, in fatal errors?? Things like
> static::$missingproperty, $this->missingmethod(), and other stuff?
> 
> Will the ?? operator
> A) make these non-fatal
> B) silently fatal (like now when @ is used)

It should be this one to be consistent. @ is shit, but sadly can not be 
avoided in all situations.

cheers,
Derick

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

Re: [PHP-DEV] ext/date arguments handling

[Derick Rethans]

Hi Florian,

On Sun, 21 Sep 2014, Florian Margaine wrote:

> I specifically mean to ask @derick about this issue I'm having, since 
> he is the maintainer of ext/date.
> 
> I wrote this pull request for the DateTimeZone::getOffset method to 
> accept a DateTimeInterface instead of a DateTime object: 
> https://github.com/php/php-src/pull/831
> 
> Instead of using ZEND_ARG_INFO, I use ZEND_ARG_OBJ_INFO rather than 
> relying on zpp only. It makes the code consistent with the type 
> hinting errors that should arise, and also gives a correct reflection.
> 
> However, the rest of the code in this extension uses ZEND_ARG_INFO, 
> only throwing warnings when the arguments are not of the right kind.
> 
> Should I use ZEND_ARG_INFO and rely on zpp's warning, or should I use 
> ZEND_ARG_OBJ_INFO, and eventually translate the other methods to use 
> it too? This'd be out of this PR of course, but it makes sense to 
> streamline the methods of ext/date.

I think it should use ZEND_ARG_OBJ_INFO. However, I am not sure whether 
we can do that in 5.x because of BC reasons. It's these tiny mistakes 
that are the larger BC problems. So I would suggest that you make a PR 
for 5.6 without ZEND_ARG_OBJ_INFO, and one for 7 with ZEND_ARG_OBJ_INFO.

I think the patch looks mostly good too. I would recommend you squash 
the commits into a single commit though.

cheers,
Derick

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

Re: [PHP-DEV] [VOTE][RFC] Integer Semantics

[Derick Rethans]

On Mon, 22 Sep 2014, Peter Cowburn wrote:

> On 22 September 2014 10:21, Pierre Joye  wrote:
> 
> > On Mon, Sep 22, 2014 at 11:02 AM, Peter Cowburn 
> > wrote:
> >
> > > If you say so. Still, the asking of individuals to remove their 
> > > votes so that the tally is in you favour is inexcusable.
> >
> > did I miss something? What is this "request to remove votes" thing?
> 
> Pierre, it didn’t take place on-list. [1] [2] [3] [4] [5]
> 
> In summary, Andrea asked individuals, myself included, several times 
> to remove their “no” votes purely to cross the 2/3 majority threshold.

I would also like to point out that, just like a 8:8 vote is not a "50% 
majority", 16:8 is technically also not a two thirds *majority*. The 
RFC, like with many other important things is of course too vague on 
this.

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

Re: [PHP-DEV] [RFC] Change checkdnsrr() $type argument behavior

[Pierre Joye]

On Mon, Sep 22, 2014 at 11:56 AM, Kris Craig  wrote:
>
> On Sep 22, 2014 2:16 AM, "Pierre Joye"  wrote:
>>
>> On Mon, Sep 22, 2014 at 10:56 AM, Kris Craig  wrote:
>> >
>> > On Sep 22, 2014 1:09 AM, "Pierre Joye"  wrote:
>> >>
>> >> On Mon, Sep 22, 2014 at 9:07 AM, Kris Craig 
>> >> wrote:
>> >> >
>> >> > On Sep 21, 2014 11:52 PM, "Pierre Joye"  wrote:
>> >>
>> >> Well, for what I can see users already take into account this part of
>> >> the issue then:
>> >>
>> >> https://github.com/search?l=php&q=checkdnsrr&type=Code&utf8=%E2%9C%93
>> >>
>> >> changing the default will make create code compatibility between 5.x
>> >> and 7.x, killing the gains we may have by changing the default.
>> >>
>> >> Cheers,
>> >> --
>> >> Pierre
>> >>
>> >> @pierrejoye | http://www.libgd.org
>> >
>> > That's why we have the option of just making that arg required without a
>> > default, which would be targetted for PHP 7.
>>
>>
>> I got that :)
>>
>> but now imagine one doing the following call now:
>>
>> checkdnsrr("myhost")  == TRUE
>>
>> where only MX was set and we suddenly change the default to ANY but
>> ANY does not include MX, then the validation will simply fail and the
>> code will become either:
>
> Why doesn't ANY include MX?  That also seems counter-intuitive, as one would
> assume that "ANY" would check for any type of record.

I meant in the case when a DNS record has no MX entry.

>>
>> checkdnsrr("myhost", 'MX')  == TRUE
>>
>> and for what I see, most of the usages are done to valid emails.
>
> Hmm that hasn't been my experience, but regardless, they should be using
> checkmxrr() for that, anyway.  As it stands now, the default behavior of
> checkdnsrr() just redundantly mirrors the behavior of another function and
> for no apparent reason.

Other are only aliases, not the other way round.


>>
>> I am not saying I am against such changes, I only do not see the gains
>> but the possible pains in a couple of situations, these pains will
>> make migration harder with no technical gains from our side.
>
> I do think it would be a usability gain, if not a technical one.  And I've
> long been of the opinion that major version increments like PHP 7 are the
> ideal time to implement such improvements, even despite some potential
> edge-case BC.
>
> What if we got rid of the option to change the default and instead just went
> with making both args required?

Same results

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

Re: [PHP-DEV] [VOTE][RFC] Integer Semantics

[Leigh]

On 22 September 2014 11:10, Andrea Faulds  wrote:
>
> If we’re going to reopen or restart, I’d prefer to completely restart it than 
> to just reopen it. A clean slate.

Most of the issues I saw raised were related to one half of the RFC,
the shifts or the casts, perhaps you'd make better headway splitting
it in two.

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

Re: [PHP-DEV] [RFC] Loop... or...

[Michael Wallner]

On 2014-09-21 02:21, Sara Golemon wrote:
> On Sat, Sep 20, 2014 at 3:03 PM, Leigh  wrote:
>> On 20 September 2014 20:47, Sara Golemon  wrote:
>>> I like the general idea, but rather than explicitly focusing on
>>> the 'or' keyword, how about just giving all loop constructs
>>> (do/while/for/foreach) a return value?  I'd suggest an integer
>>> return value indicating the number of times the loop executed.
>>> 
>> 
>> mind === blown
>> 
>> This would open up a huge amount of other functionality I'd never 
>> dreamed of (some of which is quite scary!)
>> 
>> for($i = for(...) {}; $i < ...) {}
>> 
> Yikes, I truly hope nobody ever writes that code.  Ever.
> 
>> I'm really not sure I understand the full implication of this
>> though. This would mean changing loop constructs from statements
>> to expressions. I wonder how difficult that will actually be, and
>> what other problems it would cause (I obviously haven't played with
>> this idea yet).
>> 
> I admit, I haven't thought it through entirely either.  Nor even if 
> it's definitely possible.
> 
>> It would also mean having to make { default block } into an 
>> expression... with a return value (to be allowed on either side of
>> the boolean or)
>> 
> Excellent point, a block only works with T_OR if it has a value.
> I'm pretty sure that at this point, it doesn't.  That does put a
> monkey wrench into it.  Perhaps a lambda could accommodate that?
> Starts to get ugly though...
> 
>> Lots to think about here, if it's at all viable this will need
>> it's own separate RFC, it's a much more invasive change, but
>> definitely a great idea.
>> 
> Yeah, I might be trying too hard. Worth exploring a tiny bit
> though...
> 
> -Sara
> 

Actually, I once or twice wanted to use while() {} else {} instead of
wrapping the loop in an "if". The extended version of Sara, while
looking great at a first glance, quickly turns into a crazy nightmare
after looking at the points already cooked up :)

-- 
Regards,
Mike

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

Re: [PHP-DEV] [VOTE][RFC] Integer Semantics

[Andrea Faulds]

On 22 Sep 2014, at 10:36, Michael Wallner  wrote:

> 
> WTF is going on here? Looks like the vote was closed nearly 24 hours
> early on a weekend. While the latter is not nice, closing early is a
> no-go. So what are we going to do? Reopen the vote for another day or
> completely restart it?

If we’re going to reopen or restart, I’d prefer to completely restart it than 
to just reopen it. A clean slate.
--
Andrea Faulds
http://ajf.me/





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

Re: [PHP-DEV] [RFC] Change checkdnsrr() $type argument behavior

[Kris Craig]

On Sep 22, 2014 2:16 AM, "Pierre Joye"  wrote:
>
> On Mon, Sep 22, 2014 at 10:56 AM, Kris Craig  wrote:
> >
> > On Sep 22, 2014 1:09 AM, "Pierre Joye"  wrote:
> >>
> >> On Mon, Sep 22, 2014 at 9:07 AM, Kris Craig 
wrote:
> >> >
> >> > On Sep 21, 2014 11:52 PM, "Pierre Joye"  wrote:
> >>
> >> Well, for what I can see users already take into account this part of
> >> the issue then:
> >>
> >> https://github.com/search?l=php&q=checkdnsrr&type=Code&utf8=%E2%9C%93
> >>
> >> changing the default will make create code compatibility between 5.x
> >> and 7.x, killing the gains we may have by changing the default.
> >>
> >> Cheers,
> >> --
> >> Pierre
> >>
> >> @pierrejoye | http://www.libgd.org
> >
> > That's why we have the option of just making that arg required without a
> > default, which would be targetted for PHP 7.
>
>
> I got that :)
>
> but now imagine one doing the following call now:
>
> checkdnsrr("myhost")  == TRUE
>
> where only MX was set and we suddenly change the default to ANY but
> ANY does not include MX, then the validation will simply fail and the
> code will become either:

Why doesn't ANY include MX?  That also seems counter-intuitive, as one
would assume that "ANY" would check for any type of record.

>
> checkdnsrr("myhost", 'MX')  == TRUE
>
> and for what I see, most of the usages are done to valid emails.

Hmm that hasn't been my experience, but regardless, they should be using
checkmxrr() for that, anyway.  As it stands now, the default behavior of
checkdnsrr() just redundantly mirrors the behavior of another function and
for no apparent reason.

>
> I am not saying I am against such changes, I only do not see the gains
> but the possible pains in a couple of situations, these pains will
> make migration harder with no technical gains from our side.

I do think it would be a usability gain, if not a technical one.  And I've
long been of the opinion that major version increments like PHP 7 are the
ideal time to implement such improvements, even despite some potential
edge-case BC.

What if we got rid of the option to change the default and instead just
went with making both args required?

--Kris

>
> Cheers,
> --
> Pierre
>
> @pierrejoye | http://www.libgd.org

Re: [PHP-DEV] [VOTE][RFC] Integer Semantics

[Lester Caine]

On 22/09/14 10:42, Pierre Joye wrote:
> This is getting really annoying. 2nd or 3rd time it happens, between
> people changing contents during votes, closing too early, too late,
> asking to change votes, etc.

At a very least a vote should not end until at least 7 days after the
last change to the RFC being voted on? But 7 days STILL seems too short
when like yourself Pierre, people can be out on the road for a week?

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

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

Re: [PHP-DEV] [VOTE][RFC] Integer Semantics

[Andrea Faulds]

On 22 Sep 2014, at 10:46, Xinchen Hui  wrote:

> ask people to vote yes,  close the vote immeditely once it reach the
> 2/3 requirement..
> 
> it's not cool,  and it's not about RFC process... it's about manner…

I didn’t close it because it reached the 2/3 requirement. I was lucky that one 
more person voted before I closed it. I made an honest mistake and closed it 
too early.
--
Andrea Faulds
http://ajf.me/





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

Re: [PHP-DEV] [VOTE][RFC] Integer Semantics

[Xinchen Hui]

On Mon, Sep 22, 2014 at 5:35 PM, Peter Cowburn  wrote:
>
>
> On 22 September 2014 10:21, Pierre Joye  wrote:
>>
>> On Mon, Sep 22, 2014 at 11:02 AM, Peter Cowburn 
>> wrote:
>>
>> >
>> > If you say so. Still, the asking of individuals to remove their votes so
>> > that the tally is in you favour is inexcusable.
>>
>> did I miss something? What is this "request to remove votes" thing?
>
>
> Pierre, it didn’t take place on-list. [1] [2] [3] [4] [5]
>
> In summary, Andrea asked individuals, myself included, several times to
> remove their “no” votes purely to cross the 2/3 majority threshold.  That,
> along with their timely concerns raised both on- and off-list about who can
> vote, leads me to think… “shenanigans”. [6]

ask people to vote yes,  close the vote immeditely once it reach the
2/3 requirement..

it's not cool,  and it's not about RFC process... it's about manner...

thanks
>
> What’s done is done, the RFC passed and was merged… let’s move along to
> getting stuff done.
>
>>
>>
>>
>> --
>> Pierre
>>
>> @pierrejoye | http://www.libgd.org
>
>
> [1] http://chat.stackoverflow.com/transcript/11?m=18895597#18895597
> [2] http://chat.stackoverflow.com/transcript/11?m=18948500#18948500
> [3] http://chat.stackoverflow.com/transcript/11?m=18986456#18986456
> [4] http://chat.stackoverflow.com/transcript/11?m=18986542#18986542
> [5] http://chat.stackoverflow.com/transcript/11?m=19003711#19003711
> [6] http://dictionary.reference.com/browse/shenanigans



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

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

Re: [PHP-DEV] [VOTE][RFC] Integer Semantics

[Pierre Joye]

On Mon, Sep 22, 2014 at 11:36 AM, Michael Wallner  wrote:
>
> WTF is going on here? Looks like the vote was closed nearly 24 hours
> early on a weekend. While the latter is not nice, closing early is a
> no-go. So what are we going to do? Reopen the vote for another day or
> completely restart it?

This is getting really annoying. 2nd or 3rd time it happens, between
people changing contents during votes, closing too early, too late,
asking to change votes, etc.

As we can't fix the lobbying part of it we can fix the time, content
and periods issue. I will drop a mail later today to propose a
solution, avoiding this.

-- 
Pierre

@pierrejoye | http://www.libgd.org

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

Re: [PHP-DEV] [VOTE][RFC] Integer Semantics

[Peter Cowburn]

On 22 September 2014 10:21, Pierre Joye  wrote:

> On Mon, Sep 22, 2014 at 11:02 AM, Peter Cowburn 
> wrote:
>
> >
> > If you say so. Still, the asking of individuals to remove their votes so
> > that the tally is in you favour is inexcusable.
>
> did I miss something? What is this "request to remove votes" thing?
>

Pierre, it didn’t take place on-list. [1] [2] [3] [4] [5]

In summary, Andrea asked individuals, myself included, several times to
remove their “no” votes purely to cross the 2/3 majority threshold.  That,
along with their timely concerns raised both on- and off-list about who can
vote, leads me to think… “shenanigans”. [6]

What’s done is done, the RFC passed and was merged… let’s move along to
getting stuff done.


>
>
> --
> Pierre
>
> @pierrejoye | http://www.libgd.org
>

[1] http://chat.stackoverflow.com/transcript/11?m=18895597#18895597
[2] http://chat.stackoverflow.com/transcript/11?m=18948500#18948500
[3] http://chat.stackoverflow.com/transcript/11?m=18986456#18986456
[4] http://chat.stackoverflow.com/transcript/11?m=18986542#18986542
[5] http://chat.stackoverflow.com/transcript/11?m=19003711#19003711
[6] http://dictionary.reference.com/browse/shenanigans

Re: [PHP-DEV] [VOTE][RFC] Integer Semantics

[Michael Wallner]

WTF is going on here? Looks like the vote was closed nearly 24 hours
early on a weekend. While the latter is not nice, closing early is a
no-go. So what are we going to do? Reopen the vote for another day or
completely restart it?

-- 
Regards,
Mike

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

Re: [PHP-DEV] [RFC] Loop... or...

[Leigh]

On 22 September 2014 08:49, Xinchen Hui  wrote:
>
> Maybe I am too conservative. I don't like this idea. :<
>
> And I DO THINK, we should try to stop brings lots of new things into PHP7.
>
> I am worring whether it can be release in the next year

Can you give some more details on why you don't like the idea? Is
there anything I can do to the proposal to make it more acceptable?

I don't think you should worry this postponing the release. I plan to
do all of the work for this, it shouldn't cost you any time at all
except a few lines about your opinion.

I'm not comfortable deep diving into the core, so it's not like I can
help make the release go faster if I stop work on this.

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

Re: [PHP-DEV] [VOTE][RFC] Integer Semantics

[Pierre Joye]

On Mon, Sep 22, 2014 at 11:02 AM, Peter Cowburn  wrote:

>
> If you say so. Still, the asking of individuals to remove their votes so
> that the tally is in you favour is inexcusable.

did I miss something? What is this "request to remove votes" thing?


-- 
Pierre

@pierrejoye | http://www.libgd.org

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

Re: [PHP-DEV] [RFC] Change checkdnsrr() $type argument behavior

[Pierre Joye]

On Mon, Sep 22, 2014 at 10:56 AM, Kris Craig  wrote:
>
> On Sep 22, 2014 1:09 AM, "Pierre Joye"  wrote:
>>
>> On Mon, Sep 22, 2014 at 9:07 AM, Kris Craig  wrote:
>> >
>> > On Sep 21, 2014 11:52 PM, "Pierre Joye"  wrote:
>>
>> Well, for what I can see users already take into account this part of
>> the issue then:
>>
>> https://github.com/search?l=php&q=checkdnsrr&type=Code&utf8=%E2%9C%93
>>
>> changing the default will make create code compatibility between 5.x
>> and 7.x, killing the gains we may have by changing the default.
>>
>> Cheers,
>> --
>> Pierre
>>
>> @pierrejoye | http://www.libgd.org
>
> That's why we have the option of just making that arg required without a
> default, which would be targetted for PHP 7.


I got that :)

but now imagine one doing the following call now:

checkdnsrr("myhost")  == TRUE

where only MX was set and we suddenly change the default to ANY but
ANY does not include MX, then the validation will simply fail and the
code will become either:

checkdnsrr("myhost", 'MX')  == TRUE

and for what I see, most of the usages are done to valid emails.

I am not saying I am against such changes, I only do not see the gains
but the possible pains in a couple of situations, these pains will
make migration harder with no technical gains from our side.

Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org

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

Re: [PHP-DEV] [RFC] Loop... or...

[Leigh]

On 22 September 2014 08:17, Christian Stoller  wrote:
>
> I like this proposal as I am using this feature in Twig very often.
> But I would really prefer using "else" instead of "or", because it
> is already common in the mentioned projects.
> Maybe you could reconsider if it is really not possible to use "else".

It's _really_ not possible to use "else" without a huge BC break in
one form or another, something I'm trying to avoid at all costs.

> What about making the brackets for the loop block obligatory for
> using this feature?

Unfortunately that wouldn't help, we'd have to enforce braces on
everything (if/else/elseif/while/for/etc) to make it possible to hang
an "else" on the bottom of a loop, again a pretty big BC break.

I have actually discussed "braces everywhere" with several internals
devs, and the response has been pretty much unanimous: We'd like it,
but it will never pass the vote. It would be trivial to provide a
migration script though. Feel free to test the water with this idea ;)

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

Re: [PHP-DEV] [VOTE][RFC] Integer Semantics

[Peter Cowburn]

On Monday, 22 September 2014, Andrea Faulds  wrote:

>
> On 21 Sep 2014, at 22:49, Peter Cowburn  > wrote:
>
> > It is closed now.
> >
> > The vote is closed now, fact.  That does not prevent further (hopefully
> productive) discussion from happening, and it also doesn’t stipulate that
> the RFC must be merged.
>
> The RFC is merged. I suppose you could revert the changes, though it’d be
> a significant hassle.


Immediately reverting a change is a knee-jerk reaction that should not take
place.

That said, this vote was closed early, whether deliberately or not, and
merged, which goes against everything we've been aiming for with the
RFC process.


>
> > Closing the vote at the most convenient opportunity, when it suits the
> author most, is not cool.
>
> I didn’t close it because the time suited me most. I made an honest
> mistake and closed it 22 or so hours early because I forgot I’d opened the
> vote at ~23:00 and not ~02:00. Unfortunately, I realised my mistake after
> merging the patch. This was definitely not intentional.


If you say so. Still, the asking of individuals to remove their votes so
that the tally is in you favour is inexcusable.


> --
> Andrea Faulds
> http://ajf.me/
>
>
>
>
>

Re: [PHP-DEV] [RFC] Change checkdnsrr() $type argument behavior

[Kris Craig]

On Sep 22, 2014 1:09 AM, "Pierre Joye"  wrote:
>
> On Mon, Sep 22, 2014 at 9:07 AM, Kris Craig  wrote:
> >
> > On Sep 21, 2014 11:52 PM, "Pierre Joye"  wrote:
>
> Well, for what I can see users already take into account this part of
> the issue then:
>
> https://github.com/search?l=php&q=checkdnsrr&type=Code&utf8=%E2%9C%93
>
> changing the default will make create code compatibility between 5.x
> and 7.x, killing the gains we may have by changing the default.
>
> Cheers,
> --
> Pierre
>
> @pierrejoye | http://www.libgd.org

That's why we have the option of just making that arg required without a
default, which would be targetted for PHP 7.

--Kris

Re: [PHP-DEV] [RFC] Change checkdnsrr() $type argument behavior

[Pierre Joye]

On Mon, Sep 22, 2014 at 9:07 AM, Kris Craig  wrote:
>
> On Sep 21, 2014 11:52 PM, "Pierre Joye"  wrote:

Well, for what I can see users already take into account this part of
the issue then:

https://github.com/search?l=php&q=checkdnsrr&type=Code&utf8=%E2%9C%93

changing the default will make create code compatibility between 5.x
and 7.x, killing the gains we may have by changing the default.

Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org

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

Re: [PHP-DEV] Internationalized Domain Name support in FILTER_VALIDATE_URL

[Lester Caine]

On 22/09/14 08:47, Andrea Faulds wrote:
>> Does anyone known if it's better to use libIDN (LGPL) or ICU (custom
>> > license deviated from the X license) from a license point of view?
> We already use ICU in many places, so it's more likely to be available and 
> people can get IDN support "for free". I suppose, then, the license isn't an 
> issue.
Has any alternative to ICU been found yet as a base for unicode support
in PHP7 in general?

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

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

Re: [PHP-DEV] [RFC] Loop... or...

[Xinchen Hui]

Hey:

On Sat, Sep 20, 2014 at 5:56 AM, Leigh  wrote:
> Hello list!
>
> This is an item that has been repeatedly requested in various forms,
> with no solid implementation to back it up, yet remaining quite
> desirable to the developer community at large.
>
> Loops with a default block, executed in the event that the loop is
> never entered.
>
> https://wiki.php.net/rfc/loop_or
>
> Traditionally this is requested as a loop {} else {} structure,
> however due to the choice of keyword this causes significant BC
> problems.
>
> I have written an RFC presenting this feature as loop {} or {} along
> with how I intend to implement it. I have consulted with several core
> contributors as well as normal developers, and this seems to be the
> most BC-complete option.
>
> A poll of local developers indicates a strong positive response
> supporting this feature, so please take the time to consider and
> discuss what is laid out in the RFC, as many of us would like this to
> become a permanent fixture of the language.
>
> I especially need input regarding Opcache concerns, as this is not an
> area of expertise for me.
>
> I will be developing the patch myself, and hope to have a full proof
> of concept completed by the end of this weekend. (for and while are
> both working, foreach currently segfaults, I am working on it)
>
> Thanks for reading.
>
> Leigh.
Maybe I am too conservative. I don't like this idea. :<

And I DO THINK, we should try to stop brings lots of new things into PHP7.

I am worring whether it can be release in the next year

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



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

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

Re: [PHP-DEV] Internationalized Domain Name support in FILTER_VALIDATE_URL

[Andrea Faulds]

> On 22 Sep 2014, at 08:18, Kévin Dunglas  wrote:
> 
> I'll implement optional (and not default) support of IDN in filter_var().
> 
> Does anyone known if it's better to use libIDN (LGPL) or ICU (custom
> license deviated from the X license) from a license point of view?

We already use ICU in many places, so it's more likely to be available and 
people can get IDN support "for free". I suppose, then, the license isn't an 
issue.

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

Re: [PHP-DEV] #68049 filter_var echo wrong result for a url

[Florian Margaine]

Sounds like a great idea! Don't forget to update
https://bugs.php.net/bug.php?id=68049 when it'll be done.


Regards,

*Florian Margaine*

On Mon, Sep 22, 2014 at 9:20 AM, Kévin Dunglas  wrote:

> I've recently proposed a refactoring of FILTER_VALIDATE_URL:
> https://github.com/php/php-src/pull/826
> I can easily add the support of this new flag is everyone agree.
>
> 2014-09-22 9:09 GMT+02:00 Florian Margaine :
>
>> Oh, IE. *sigh*
>>
>> Adding a new flag sounds like a good idea indeed,
>> `FILTER_VALIDATE_UNCOMPLIANT_URL` sounds good enough?
>>
>> I guess it should accept underscores and domain names starting with
>> numbers too.
>>
>> Regards,
>>
>> *Florian Margaine*
>>
>> P.S: sorry Kevin for the double mail.
>> Le 22 sept. 2014 09:03, "Kévin Dunglas"  a écrit :
>>
>>> Some browsers do. Some versions of IE are buggy when the URL include
>>> underscores:
>>> http://stackoverflow.com/questions/794243/internet-explorer-ignores-cookies-on-some-domains-cannot-read-or-set-cookies
>>>
>>>
>>> I think that filter_var must follow the RFC by default. Maybe can we add
>>> a flag to allow malformed URL in use in the wild?
>>>
>>>
>>>
>>> 2014-09-21 10:42 GMT+02:00 Florian Margaine :
>>>
 Hi,

 According to https://bugs.php.net/bug.php?id=51192 , valid URLs cannot
 contain underscores.

 The following bug was reported a couple days ago:
 https://bugs.php.net/bug.php?id=68049

 The thing is, browsers *do* accept the underscore in URLs. Should the
 rfc3986  be
 respected, or
 should PHP be lenient like browsers and accept more?

 Regards,

 *Florian Margaine*

>>>
>>>
>>>
>>> --
>>> Kévin Dunglas
>>> Consultant et développeur freelance
>>>
>>> http://dunglas.fr
>>> Tél. : 06 60 91 20 20
>>>
>>
>
>
> --
> Kévin Dunglas
> Consultant et développeur freelance
>
> http://dunglas.fr
> Tél. : 06 60 91 20 20
>

[PHP-DEV] Re: OpenSSL bug in 5.4.33 and 5.5.17

[Arjen Schol]

I noticed a regression in 5.5.17RC1, reported it (#67965) and it got 
fixed in f86b2193 on the 5.5 branch by Daniel Lowrey.


But this fix didn't make it in 5.5.17 final. I posted the following 
message on the 5.5.17RC1 release announcement:



What's the benefit of doing a Release Candidate/QA cycle when fixes for 
regressions aren't merged to the final release?

See https://bugs.php.net/bug.php?id=67965
Regression reported and fixed, but fix not merged to 5.5.17 branch.

Commit 
https://github.com/php/php-src/commit/f86b2193a483f56b0bd056570a0cdb57ebe66e2f?diff=unified
File in 5.5.17: 
https://github.com/php/php-src/blob/PHP-5.5.17/ext/openssl/xp_ssl.c#L884

Not critical enough? Just missed it? RC releases just for the show? :?


Who is resposible for cherrypicking fixes for regressions in release 
candidates? The release manager? The developer who commited the fix? Did 
the release manager ever considered including this fix in the final 
version? Where are regressions tracked?


The issues tracker didn't have a 'PHP5.5.15RC1' version, so bugs are 
filled against '5.5Git-2014-09-05' which makes it difficult to track 
issues specific on 5.5.17RC1. PHP 5.6.1.RC1 however, IS listed as a 
version on https://bugs.php.net/report.php


The releaseprocess RFC (https://wiki.php.net/rfc/releaseprocess) does 
not address these issues.


Arjen



On 09/19/2014 06:49 PM, Remi Collet wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Le 19/09/2014 18:25, Daniel Lowrey a écrit :

In an effort to fix a very old (seven years old) DoS
vulnerability involving encrypted streams I created a
regression where feof() notifications on encrypted sockets are
broken. This is present in both the most recent 5.4.33 and
5.5.17 releases.



Can you please point us to the related commit... (which one cause
the regression, which ones are useful)


In 5.4.33 and 5.5.17 an immediate fix is to revert these commits:

http://git.php.net/?p=php-src.git;a=commitdiff;h=6569db88081562f68a4f79e52cba83482bdf05fc


http://git.php.net/?p=php-src.git;a=commitdiff;h=372844918a318ad712e16f9ec636682424a65403


http://git.php.net/?p=php-src.git;a=commitdiff;h=32be79dcfa1bc5af8682d9f512da68c5b3e2cbf3

  The last of these (32be79d) has already been fixed upstream by
f86b2193a483f56b0bd056570a0cdb57ebe66e2f but this change did not go
into 5.4.33 and 5.5.17. Any reverts should also consider f86b2193.


Does a revert of the first enough to get back to previous
behavior?


Yes, reverting the above commits above will fix any issues. I'm
awaiting word from someone associated with Horde to verify that the
previously linked patch (
https://bugs.php.net/patch-display.php?bug=41631&patch=bug41631.patch&revision=1411139621)



resolves the issue. As long as that works as expected I can merge that and

everything should be resolved going forward.



After a quick check

6569db8 and 32be79d are in 5.4.33 / 5.5.17 / 5.6.1RC1
f86b219 and 3728449 are in 5.6.1RC1 only


-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlQcXrUACgkQYUppBSnxahgfigCfUYmoYXJJYC0JKmLi/tg+mo1r
mwwAoNXbDpPsdrVfzFWUy4tuOssqR256
=OUHp
-END PGP SIGNATURE-




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

Re: [PHP-DEV] #68049 filter_var echo wrong result for a url

[Kévin Dunglas]

I've recently proposed a refactoring of FILTER_VALIDATE_URL:
https://github.com/php/php-src/pull/826
I can easily add the support of this new flag is everyone agree.

2014-09-22 9:09 GMT+02:00 Florian Margaine :

> Oh, IE. *sigh*
>
> Adding a new flag sounds like a good idea indeed,
> `FILTER_VALIDATE_UNCOMPLIANT_URL` sounds good enough?
>
> I guess it should accept underscores and domain names starting with
> numbers too.
>
> Regards,
>
> *Florian Margaine*
>
> P.S: sorry Kevin for the double mail.
> Le 22 sept. 2014 09:03, "Kévin Dunglas"  a écrit :
>
>> Some browsers do. Some versions of IE are buggy when the URL include
>> underscores:
>> http://stackoverflow.com/questions/794243/internet-explorer-ignores-cookies-on-some-domains-cannot-read-or-set-cookies
>>
>>
>> I think that filter_var must follow the RFC by default. Maybe can we add
>> a flag to allow malformed URL in use in the wild?
>>
>>
>>
>> 2014-09-21 10:42 GMT+02:00 Florian Margaine :
>>
>>> Hi,
>>>
>>> According to https://bugs.php.net/bug.php?id=51192 , valid URLs cannot
>>> contain underscores.
>>>
>>> The following bug was reported a couple days ago:
>>> https://bugs.php.net/bug.php?id=68049
>>>
>>> The thing is, browsers *do* accept the underscore in URLs. Should the
>>> rfc3986  be
>>> respected, or
>>> should PHP be lenient like browsers and accept more?
>>>
>>> Regards,
>>>
>>> *Florian Margaine*
>>>
>>
>>
>>
>> --
>> Kévin Dunglas
>> Consultant et développeur freelance
>>
>> http://dunglas.fr
>> Tél. : 06 60 91 20 20
>>
>


-- 
Kévin Dunglas
Consultant et développeur freelance

http://dunglas.fr
Tél. : 06 60 91 20 20

Re: [PHP-DEV] Internationalized Domain Name support in FILTER_VALIDATE_URL

[Kévin Dunglas]

I'll implement optional (and not default) support of IDN in filter_var().

Does anyone known if it's better to use libIDN (LGPL) or ICU (custom
license deviated from the X license) from a license point of view?

2014-09-19 16:18 GMT+02:00 Chris Wright :

> On 19 September 2014 14:48, Kévin Dunglas  wrote:
> > Support of IDN in streams is a must have.
> > But there is a lot of other use cases for URL with IDN validation. The
> most
> > common is probably form validation (test if an user submitted URL has a
> > valid format and can be used to create an HTML link...).
> >
> > I'm ok making IDN validation optional and not used by default until PHP
> > natively support IDN in other features such as streams.
> > But IDN are used more and more in the wild, and from a user point of
> view it
> > is disappointing that a valid URL, working in browsers and even
> displayed by
> > Google Search is not considered as a valid URL by a PHP-based website
> using
> > filter_var() without a specific flag.
> >
> > Even some TLD are using non-ASCII characters, exemple: http://旅游气象.中国
> 
> > (popular Chinese weather site).
> >
> > About the library, I've not preference between libidn and icu. If the
> > licence is libidn fit better with the PHP one, libidn is probably the
> better
> > choice. Having a PHP specific implementation of STRINGPREP and Punnycode
> > sounds not like a good idea (reinventing the wheel, more code to
> maintain).
> >
> > Chris, is there a chance to have your work on streams merged in PHP 7?
>
> It's very hacky and PoC at the moment. I've got a bunch of
> time-consuming personal things going on right now, but within the next
> couple of weeks I will try and polish it up into something
> serviceable, maintainable and tested/less likely to explode with
> edge-cases and then I'll put it up for discussion.
>
> I'm also fine if someone else wants to have a crack in the meantime, I
> can push my work so far to github early next week when I get access to
> the machine.
>
> I'd certainly like the functionality to be in 7 if it's viable from a
> licensing and dependency PoV - I had been holding off bringing it up
> to see what happened with the more general unicode support discussion
> (which I somewhat lost track of and seems to have died out) as there
> was talk of introducing a hard dependency on ICU-or-similar at one
> point, which would have made this a no-brainer.
>
> > What do you thing about the following planning:
> > - 5.7 (if exists): add IDN support in filter disabled by default. Use
> libidn
> > if selected to be used for streams too.
> > - 7 (if IDN support for streams is completed): validate IDN by default
> (what
> > the user expect), add a flag to disable IDN validation. Of course we'll
> > update the doc explaining the new behavior.
> >
> > 2014-09-19 12:28 GMT+02:00 Chris Wright :
> >>
> >> On 19 September 2014 10:58, Pierre Joye  wrote:
> >> > Hi,
> >> >
> >> > On Sep 19, 2014 4:03 PM, "Chris Wright"  wrote:
> >> >>
> >> >> Kévin
> >> >>
> >> >> On 18 September 2014 21:26, Kévin Dunglas  wrote:
> >> >> > Hello,
> >> >> >
> >> >> > I'm working on enhancing the FILTER_VALIDATE_URL filter (
> >> >> > https://github.com/php/php-src/pull/826).
> >> >> > The current implementation does not support validation of
> >> >> > internationalized
> >> >> > domain names (i.e: http://www.académie-française.fr/
> 
> >> >> > ).
> >> >> >
> >> >> > Support of IDN validation can be easily added using ICU's
> >> >> > uidna_toASCII()
> >> >> > function.
> >> >> >
> >> >> > Is it acceptable to add a dependency to ICU for ext/filter?
> >> >> > Another option is to add a HAVE_ICU constant in main/php_config.h
> and
> >> >> > to
> >> >> > validate IDN only if ICU is present.
> >> >> >
> >> >> > What strategy is preferred?
> >> >>
> >> >> I've done some work around this area previously, and all I will say
> >> >> is: be careful with what you do with this from a userland PoV.
> >> >>
> >> >> PHP does not natively support IDN in stream open routines or SSL
> >> >> verification routines. It will never support these things without at
> >> >> least one of:
> >> >> - a core dependency on ICU, libidn or similar
> >> >> - moving streams into an extension so a dependency can be introduced
> >> >> there (probably not sanely possible)
> >> >> - an in-house NAMEPREP implementation (this is the hard part of IDN,
> >> >> punycode itself is pretty trivial to implement once you have a
> >> >> canonical set of codepoints)
> >> >>
> >> >> These things can be implemented with *a lot* of boilerplate in
> >> >> userland when you have ext/intl, but it's not pretty. libcurl *can*
> >> >> support IDN if it was built against libidn, I'm not sure if this is
> >> >> currently the case in common distributions or not. Since one almost
> >> >> never just validates a URL string, it's usually a precursor to
> >> >> attempting to op

RE: [PHP-DEV] [RFC] Loop... or...

[Christian Stoller]

From: Leigh [mailto:lei...@gmail.com] Sent: Friday, September 19, 2014 11:57 PM
>
> Traditionally this is requested as a loop {} else {} structure,
> however due to the choice of keyword this causes significant BC
> problems.
>
> I have written an RFC presenting this feature as loop {} or {} along
> with how I intend to implement it. I have consulted with several core
> contributors as well as normal developers, and this seems to be the
> most BC-complete option.

I like this proposal as I am using this feature in Twig very often.
But I would really prefer using "else" instead of "or", because it
is already common in the mentioned projects.
Maybe you could reconsider if it is really not possible to use "else".

What about making the brackets for the loop block obligatory for
using this feature?

Christian

Re: [PHP-DEV] #68049 filter_var echo wrong result for a url

[Florian Margaine]

Oh, IE. *sigh*

Adding a new flag sounds like a good idea indeed,
`FILTER_VALIDATE_UNCOMPLIANT_URL` sounds good enough?

I guess it should accept underscores and domain names starting with numbers
too.

Regards,

*Florian Margaine*

P.S: sorry Kevin for the double mail.
Le 22 sept. 2014 09:03, "Kévin Dunglas"  a écrit :

> Some browsers do. Some versions of IE are buggy when the URL include
> underscores:
> http://stackoverflow.com/questions/794243/internet-explorer-ignores-cookies-on-some-domains-cannot-read-or-set-cookies
>
> I think that filter_var must follow the RFC by default. Maybe can we add a
> flag to allow malformed URL in use in the wild?
>
>
>
> 2014-09-21 10:42 GMT+02:00 Florian Margaine :
>
>> Hi,
>>
>> According to https://bugs.php.net/bug.php?id=51192 , valid URLs cannot
>> contain underscores.
>>
>> The following bug was reported a couple days ago:
>> https://bugs.php.net/bug.php?id=68049
>>
>> The thing is, browsers *do* accept the underscore in URLs. Should the
>> rfc3986  be respected,
>> or
>> should PHP be lenient like browsers and accept more?
>>
>> Regards,
>>
>> *Florian Margaine*
>>
>
>
>
> --
> Kévin Dunglas
> Consultant et développeur freelance
>
> http://dunglas.fr
> Tél. : 06 60 91 20 20
>

Re: [PHP-DEV] [RFC] Change checkdnsrr() $type argument behavior

[Kris Craig]

On Sep 21, 2014 11:52 PM, "Pierre Joye"  wrote:
>
> hi Kris,
>
> On Sat, Sep 20, 2014 at 4:15 AM, Kris Craig  wrote:
> > Per discussion in an earlier thread.  Here's the RFC:
> >
> > https://wiki.php.net/rfc/checkdnsrr-default-type
> >
> >
> > Basically, this RFC seeks to make it so that PHP's checkdnsrr()
function,
> > which is most commonly used to see whether or not a hostname exists, no
> > longer restricts itself to only MX records by default.
> >
> > Though the RFC itself is a no-brainer, the more difficult question is
which
> > solution should be implemented.  The two options currently presented are
> > changing default from "MX" to "ANY", which would cause it to check all
> > records and not just MX; and getting rid of the default altogether and
> > making it so that the argument is required.
> >
> > From what I can tell, there are valid arguments to be made for both, so
I
> > would love to see some discussion/debate here regarding which solution
> > should be implemented, as I'm currently undecided.  Also please feel
free
> > to point out any areas of improvement for the RFC itself.
>
> I am not sure which problem this RFC tries to solve, do you have any
> example showing the issues please?
>
> Cheers,
> --
> Pierre
>
> @pierrejoye | http://www.libgd.org

It's not a bug or anything.  The problem is that the current behavior is
very counter-intuitive, not to mention unnecessary because there's already
another function dedicated to MX lookups.

At my job, we wasted a good deal of time troubleshooting what appeared to
be a weird DNS issue that turned out to just be a checkdnsrr() lookup that
was looking only for MX records because a second argument wasn't passed.  I
cannot think of any use case served by this behavior.

--Kris

Re: [PHP-DEV] #68049 filter_var echo wrong result for a url

[Kévin Dunglas]

Some browsers do. Some versions of IE are buggy when the URL include
underscores:
http://stackoverflow.com/questions/794243/internet-explorer-ignores-cookies-on-some-domains-cannot-read-or-set-cookies

I think that filter_var must follow the RFC by default. Maybe can we add a
flag to allow malformed URL in use in the wild?



2014-09-21 10:42 GMT+02:00 Florian Margaine :

> Hi,
>
> According to https://bugs.php.net/bug.php?id=51192 , valid URLs cannot
> contain underscores.
>
> The following bug was reported a couple days ago:
> https://bugs.php.net/bug.php?id=68049
>
> The thing is, browsers *do* accept the underscore in URLs. Should the
> rfc3986  be respected,
> or
> should PHP be lenient like browsers and accept more?
>
> Regards,
>
> *Florian Margaine*
>



-- 
Kévin Dunglas
Consultant et développeur freelance

http://dunglas.fr
Tél. : 06 60 91 20 20