subject:"\[PHP\-DEV\] voting"

 I am aware of this, but unless I just missed it that site doesn't show
 *when* they got an account.

None of these accounts are recent as far as I can tell from my email
archive.  For the record, with the exception of Eli - with whom I discussed
the reasons he voted against the Coercive RFC - I haven’t spoken with any of
them and doubt anybody else did (not that it would have been forbidden if I
or someone else did).
Florian (IMHO obvious) explanation is the correct one.  Take spriebsch for
example - a very prominent figure in the PHP community, hardly a newcomer -
and I guess it's the first time he finds something that's sufficiently
important for him to vote on.  We should really stop with the ridiculous 
offensive conspiracy theories.

Zeev

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

[PHP-DEV] Voting irregularities

2015-03-15 Thread Anthony Ferrara

All,

I ran some numbers on the current votes of the dual-mode vote right
now. There were a number of voters that I didn't recognize. So I
decided to pull some stats.

The following voters never voted before the dual-mode RFC went up:

dom - no
eliw - no
kguest - yes
kk - no
nohn - no
oliver - yes
richsage - yes
sammywg - no
spriebsch - no
srain - no
theseer - no
zimt - no

Some of these names I recognize from list (sammywg and eliw), but many I do not.

The interesting thing happens when you look at the voting direction.

Currently, the RFC is slightly losing 70:37 (65.4%).

If we look at percentages, 4.2% of yes voters have never voted in a
prior RFC. But a whopping 24.3% of no voters have never voted before.

If we adjust the votes to remove these never voted accounts, it
stands at 67:28. Which is 70.5%. Which is basically where the vote was
prior to the competing RFC opening.

I'm not saying that all of these are bad votes. Nor that they
shouldn't be counted. I think it does raise a significant question
around the voting practices.

Something that I think we need to discuss as a group.

So consider that discussion open.

Anthony

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

Re: [PHP-DEV] Voting irregularities

2015-03-15 Thread Pádraic Brady

Hi Michael,

On 15 March 2015 at 14:29, Michael Wallner m...@php.net wrote:

 Jeez, that is becoming ridiculous. So, if you’re that good in counting, how 
 many did not vote before STHv0.3?
 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php


I don't think it's ridiculous in a separate thread around discussing
voting practices. Anthony specifically notes that he is not calling
them bad, or calling for them to be ignored in the context of the
current RFCs. Merely noting that their existence has skewed this
particular vote, as a recent ongoing example, which it has. I have to
make an admission here, I cast a vote. I'm not on Anthony's list
because I have used it previously a couple of times. I'm honestly a
bit hesitant to believe I should have it, so I've deliberately
moderated my voting. However, watching those with no prior voting
history/or minimal history vote No compelled me to use it if only to
offset one more arguably irregular vote by casting an opposing
arguably irregular vote.

Should people like me have a vote? I got it by contributing some code
to PEAR long ago before I moved onto Zend Framework stuff, Mockery,
and other things. I consider it a relatively small contribution, and
the list makes clear many would prefer I didn't have a vote on that
basis. I don't necessarily disagree with that sentiment, but we're
stuck with the situation where contentious votes bring up the who
deserves the right to vote debate from both sides (Anthony is hardly
going solo in airing it here).

The entire idea that such arguably irregular votes are spoiling RFC
votes, i.e. not reflective of what the majority would consider votes
by those who truly earned it, has been brought up by both sides to
RFCs inside and outside of this list.

Paddy

--
Pádraic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com

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

Re: [PHP-DEV] Voting irregularities

2015-03-15 Thread Levi Morrison

On Sun, Mar 15, 2015 at 9:30 AM, Michael Wallner m...@php.net wrote:

 On 15 03 2015, at 16:23, Levi Morrison le...@php.net wrote:

 On Sun, Mar 15, 2015 at 8:29 AM, Michael Wallner m...@php.net wrote:


 On 15 03 2015, at 15:19, Anthony Ferrara ircmax...@gmail.com wrote:

 All,

 I ran some numbers on the current votes of the dual-mode vote right
 now. There were a number of voters that I didn't recognize. So I
 decided to pull some stats.

 The following voters never voted before the dual-mode RFC went up:

 dom - no
 eliw - no
 kguest - yes
 kk - no
 nohn - no
 oliver - yes
 richsage - yes
 sammywg - no
 spriebsch - no
 srain - no
 theseer - no
 zimt - no

 Some of these names I recognize from list (sammywg and eliw), but many I do
 not.

 The interesting thing happens when you look at the voting direction.

 Currently, the RFC is slightly losing 70:37 (65.4%).

 If we look at percentages, 4.2% of yes voters have never voted in a
 prior RFC. But a whopping 24.3% of no voters have never voted before.

 If we adjust the votes to remove these never voted accounts, it
 stands at 67:28. Which is 70.5%. Which is basically where the vote was
 prior to the competing RFC opening.

 I'm not saying that all of these are bad votes. Nor that they
 shouldn't be counted. I think it does raise a significant question
 around the voting practices.

 Something that I think we need to discuss as a group.

 So consider that discussion open.


 Jeez, that is becoming ridiculous. So, if you’re that good in counting, how
 many did not vote before STHv0.3?


 Is there a way to check when someone got a php.net account/karma?


 http://people.php.net


I am aware of this, but unless I just missed it that site doesn't show
*when* they got an account.

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

Re: [PHP-DEV] Voting irregularities

2015-03-15 Thread Philip Sturgeon

On Sun, Mar 15, 2015 at 12:26 PM, Zeev Suraski z...@zend.com wrote:
 I am aware of this, but unless I just missed it that site doesn't show
 *when* they got an account.

 None of these accounts are recent as far as I can tell from my email
 archive.  For the record, with the exception of Eli - with whom I discussed
 the reasons he voted against the Coercive RFC - I haven’t spoken with any of
 them and doubt anybody else did (not that it would have been forbidden if I
 or someone else did).
 Florian (IMHO obvious) explanation is the correct one.  Take spriebsch for
 example - a very prominent figure in the PHP community, hardly a newcomer -
 and I guess it's the first time he finds something that's sufficiently
 important for him to vote on.  We should really stop with the ridiculous 
 offensive conspiracy theories.

 Zeev

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


Literally nothing Anthony said was ridiculous or a conspiracy theory.

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

Re: [PHP-DEV] Voting irregularities

2015-03-15 Thread Florian Anderiasch

On 15.03.2015 16:44, Pádraic Brady wrote:
 
 I don't think it's ridiculous in a separate thread around discussing
 voting practices. Anthony specifically notes that he is not calling
 them bad, or calling for them to be ignored in the context of the
 current RFCs. Merely noting that their existence has skewed this
 particular vote, as a recent ongoing example, which it has. I have to
 make an admission here, I cast a vote. I'm not on Anthony's list
 because I have used it previously a couple of times. I'm honestly a
 bit hesitant to believe I should have it, so I've deliberately
 moderated my voting. However, watching those with no prior voting
 history/or minimal history vote No compelled me to use it if only to
 offset one more arguably irregular vote by casting an opposing
 arguably irregular vote.

Maybe many people don't see it that way, but for example for me there's
hardly been any RFC that would shape the *spirit* of the language as
much as this RFC. So I think that's a perfectly valid reason to - for
the first time ever - pitch in with your vote, even if it's not the case
for me personally.

 The entire idea that such arguably irregular votes are spoiling RFC
 votes, i.e. not reflective of what the majority would consider votes
 by those who truly earned it, has been brought up by both sides to
 RFCs inside and outside of this list.

I don't think it's possible to create a system that

a) represents the majority of PHP users
b) represents the most active contributors to internals
c) can't be gamed in any way.

We have this system now and until a RFC comes along to change voting
rights or revert to the old do what you want until someone calls you
out on it there's hardly some constructive discussion about it in all
the threads where it came up.

Greetings,
Florian

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

Re: [PHP-DEV] Voting irregularities

2015-03-15 Thread Michael Wallner


 On 15 03 2015, at 15:19, Anthony Ferrara ircmax...@gmail.com wrote:
 
 All,
 
 I ran some numbers on the current votes of the dual-mode vote right
 now. There were a number of voters that I didn't recognize. So I
 decided to pull some stats.
 
 The following voters never voted before the dual-mode RFC went up:
 
 dom - no
 eliw - no
 kguest - yes
 kk - no
 nohn - no
 oliver - yes
 richsage - yes
 sammywg - no
 spriebsch - no
 srain - no
 theseer - no
 zimt - no
 
 Some of these names I recognize from list (sammywg and eliw), but many I do 
 not.
 
 The interesting thing happens when you look at the voting direction.
 
 Currently, the RFC is slightly losing 70:37 (65.4%).
 
 If we look at percentages, 4.2% of yes voters have never voted in a
 prior RFC. But a whopping 24.3% of no voters have never voted before.
 
 If we adjust the votes to remove these never voted accounts, it
 stands at 67:28. Which is 70.5%. Which is basically where the vote was
 prior to the competing RFC opening.
 
 I'm not saying that all of these are bad votes. Nor that they
 shouldn't be counted. I think it does raise a significant question
 around the voting practices.
 
 Something that I think we need to discuss as a group.
 
 So consider that discussion open.

Jeez, that is becoming ridiculous. So, if you’re that good in counting, how 
many did not vote before STHv0.3?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Voting irregularities

2015-03-15 Thread Rowan Collins


On 15/03/2015 14:19, Anthony Ferrara wrote:

All,

I ran some numbers on the current votes of the dual-mode vote right
now. There were a number of voters that I didn't recognize. So I
decided to pull some stats.

The following voters never voted before the dual-mode RFC went up:

dom - no
eliw - no
kguest - yes
kk - no
nohn - no
oliver - yes
richsage - yes
sammywg - no
spriebsch - no
srain - no
theseer - no
zimt - no

Some of these names I recognize from list (sammywg and eliw), but many I do not.

The interesting thing happens when you look at the voting direction.

Currently, the RFC is slightly losing 70:37 (65.4%).

If we look at percentages, 4.2% of yes voters have never voted in a
prior RFC. But a whopping 24.3% of no voters have never voted before.


I think calling this an irregularity is going a bit far. It's an 
interesting observation, but since this is such a contentious issue, the 
question I would be asking is what these people have in common that 
makes them likely to vote no - are they from a particular part of the 
community whose voice is less often heard, for instance?


As I've just said on Twitter before seeing this thread, these are really 
small sample sizes, and the way you've framed the statistics there makes 
it sound more significant than it is. Wolfram Alpha tells me that if 12 
people chose their vote by tossing a coin, there's a probability of 
0.073 that 9 of them would vote the same way, which is higher than the 
threshold of 0.05 traditionally set for significance. I don't know if 
that's a valid statistic, but it's at least as scientific as your 
whopping 24.3%.


If you look at those users as a proportion of the complete turnout, 
you get 11.11% (1 in 9) votes coming from first-time voters. The net 
impact is 6 votes out of 108, which is about 5.5%; that happens to be 
enough to stop this vote crossing the line right now, but only because 
the vote is so close anyway.



If we adjust the votes to remove these never voted accounts, it
stands at 67:28. Which is 70.5%. Which is basically where the vote was
prior to the competing RFC opening.


If you exclude an arbitrary subset of votes in a close ballot like this, 
it's easy to edge it past the finishing post, but that's really an abuse 
of statistics. For instance, you could say that if the vote was closed 
on date X, the result would have been Y, but you can't know that there 
weren't people who'd already decided which way they were voting, but 
hadn't got round to logging in, because they knew the vote wasn't due to 
close yet.


With more research, you could come up with other interesting subsets, 
like people who've voted less than X times, or not voted in the last X 
months. But if you're going to play with statistics, you should be 
rigourous in defining your hypothesis, and how you'll measure the 
significance of your result. Alternatively, leave the statistics out of 
it, and say that you're interested to know why these first-time voters 
voted how they did.


Regards,

--
Rowan Collins
[IMSoP]


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

Re: [PHP-DEV] Voting irregularities

2015-03-15 Thread Levi Morrison

 What we need, is a MANAGER! To manage the Type Hint development. And one
 that is not doing real development on PHP core, but someone with
 understanding.

You are basically saying we should hand development of a critical
language feature over to someone not doing real development on the
language. I don't see how that could possibly end well.

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

Re: [PHP-DEV] Voting irregularities

2015-03-15 Thread Derick Rethans

Rowan Collins rowan.coll...@gmail.com schreef op 15 maart 2015 17:59:17 
GMT+00:00:
On 15/03/2015 14:19, Anthony Ferrara wrote:
 All,

 I ran some numbers on the current votes of the dual-mode vote right
 now. There were a number of voters that I didn't recognize. So I
 decided to pull some stats.

 The following voters never voted before the dual-mode RFC went up:

 dom - no
 eliw - no
 kguest - yes
 kk - no
 nohn - no
 oliver - yes
 richsage - yes
 sammywg - no
 spriebsch - no
 srain - no
 theseer - no
 zimt - no

 Some of these names I recognize from list (sammywg and eliw), but
many I do not.

 The interesting thing happens when you look at the voting direction.

 Currently, the RFC is slightly losing 70:37 (65.4%).

 If we look at percentages, 4.2% of yes voters have never voted in a
 prior RFC. But a whopping 24.3% of no voters have never voted before.

I think calling this an irregularity is going a bit far. 
I don't think it's going to far, if you have people with no clue writing this:

https://plus.google.com/+KristianK%C3%B6hntopp/posts/ijoDNH2M8mB

Which post says that we're turning PHP into Java. And to this misguided FUD 
post, that actively asks people to vote no, I can quite easily attribute a few 
more no votes of people that had never voted before...

Too late to tighten up the rules for this one, but something is definitely not 
right with the current process.

Cheers,
Derick
-- 
http://derickrethans.nl | http://xdebug.org
twitter: @derickr and @xdebug

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

AW: [PHP-DEV] Voting irregularities

2015-03-15 Thread Robert Stoll

 -Ursprüngliche Nachricht-
 Von: Matthew Leverton [mailto:lever...@gmail.com]
 Gesendet: Sonntag, 15. März 2015 20:46
 An: Anthony Ferrara
 Cc: internals@lists.php.net
 Betreff: Re: [PHP-DEV] Voting irregularities
 
 On Sun, Mar 15, 2015 at 9:19 AM, Anthony Ferrara ircmax...@gmail.com wrote:
  All,
 
  I ran some numbers on the current votes of the dual-mode vote right
  now. There were a number of voters that I didn't recognize. So I
  decided to pull some stats.
 
 ...
 
  Something that I think we need to discuss as a group.
 
  So consider that discussion open.
 
 I think this is likely because the votes are made public during voting phase. 
 To me, that is a bad thing. It makes for an ugly
 voting period.
 That sort of politics should happen during the discussion phase.
 
 So I don't think there's anything wrong with first time voters
 voting No en masse here. I just think there's a major problem in having a 
 real-time count of votes during the voting period.
 
 If votes weren't made public during the voting, then more people would vote 
 on more issues... avoiding this situation
 where people come from nowhere to cast a vote as word gets out on blogs 
 that something terrible is about to happen.
 
 In short, I think the real-time public vote results causes a few problems:
 
 1) Bandwagon voting, or vote for the winner mindset. The early wave of 
 voters can impact the results by discouraging
 people from voting.
 (Look at Zeev's RFC vote count vs Anthony's.)
 2) The losing side feverishly drumming up votes, often with scare tactics - 
 i.e., vocal minority. (It's much easier for the No
 side of any vote to appeal to this.)
 3) In rare cases, Gaming the system - closing the vote at the exact time that 
 benefits the owner of the RFC.
 
 So I don't think there's anything sinister here. It's just the natural result 
 of the voting rules.
 
 --
 Matthew Leverton
 
 --
 PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: 
 http://www.php.net/unsub.php

I agree with Matthew here, the voting process should be revised and votes 
should not be public -- for anyone -- until closed. I mean, every sane 
democratic country is using the secret ballot method, why shouldn't PHP use it?

But I am not a voter, so just my 2 cents

Cheers, Robert


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

Re: [PHP-DEV] Voting irregularities

2015-03-15 Thread Eli

On 3/15/15 10:19 AM, Anthony Ferrara wrote:
 [...]
 The following voters never voted before the dual-mode RFC went up:
 [...]
 eliw - no
 [...]
 Some of these names I recognize from list (sammywg and eliw), but many I do 
 not.
 [...]
 I'm not saying that all of these are bad votes. Nor that they
 shouldn't be counted. I think it does raise a significant question
 around the voting practices.

Hello Anthony ... given I was 'called out' here I figured I should
respond.  My vote (and the situation around it) is exactly what people
have assumed.  That is:

1. I've long been a member (prominent by some people's definitions) of
the PHP Community

2. I've long been a member of Internals, and read everything, and at
times join the discussion when I feel I have something to contribute. 
(If I don't, then I don't clutter the list - there's enough clutter and
enough amazingly smart people on this list, like both you and Zeev, that
I'm content to read the excellent discussions)

3. I was long (long) ago offered an acct to have a vote, and actually
declined because I didn't feel it warranted.

4. A while ago, I ended up getting an acct anyway, because I started
helping out with the documentation/webmaster/calendar stuff which noone
else was doing

5. I still never used my vote, on any issues, even the PHP 7 one which I
was one of the main instigators of.  Because I, like Padraig, kinda was
in that mentality that I shouldn't use it.  And that I would wait, until
there was a proposal that I felt very strongly about, and where my
vote/my voice could make a difference.  To cast my vote.

And so in this case, my first case.  I did cast a vote.

And unfortunately I have received no end of private (and some public)
flak about said vote.  And while I know that you are just looking at
numbers and being open about 'Hey this is interesting lets chat about
this'.  Others have not been so kind.

FWIW - I would always assume the best of people - And I would assume
that others on that voting list in fact were in similar situations. 
Where they hadn't voted before simply because they didn't feel they felt
strongly enough about something.   Also this is the first 'on the edge'
hyper-contentious vote in quite a while, which means that lurkers are
much more likely to have it come to their attention that this vote is
happening, and therefore that they should familiarize themselves with it
and cast a vote.

As to why so many of those 1st time voters, who have decided their vote
is worthwhile, happen to be voting no more often than not.  Well I have
other theories on that (which do not include any negative consequences
or foul play, but simple cases of human mentality and 'community' vs
'community' discussions)

In service to PHP,
Eli

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




signature.asc
Description: OpenPGP digital signature

RE: [PHP-DEV] Voting irregularities

 -Original Message-
 From: Philip Sturgeon [mailto:pjsturg...@gmail.com]
 Sent: Sunday, March 15, 2015 6:31 PM
 To: Zeev Suraski
 Cc: Levi Morrison; Michael Wallner; internals@lists.php.net
 Subject: Re: [PHP-DEV] Voting irregularities

 Literally nothing Anthony said was ridiculous or a conspiracy theory.

Phil,

I disagree.  'New' voters voting sharply in favor of No strongly implies
some sort of foul play.  Why break it down otherwise?  I'm not saying that
all of these votes are bad is equivalent to saying I am saying that some
of these votes are bad.  It's further strengthened by providing numbers of
where this RFC would be at if these votes were discounted, as if it's on the
table (that, I would argue, is the ridiculous part).  Also, it really
doesn't matter what you or I think about it.  What matters is what everyone
thinks about it.  We already have one person understanding this email as a
reason to look into when these accounts were created, and judging from the
Twitter messages, he's not alone in suspecting some sort of foul play.

I absolutely do think we should revisit our voting practices, but absolutely
not in the context of a specific RFC, and not mid-flight.  The quiet period
after PHP 7's RFCs close could be an appropriate time for that.

Zeev

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

Re: [PHP-DEV] Voting irregularities

2015-03-15 Thread Arvids Godjuks

C'mon guys, vote didn't pass, it's time to do something about it and not
start conspiracy theories (or I will loose hope for humanity completely). I
happened to have a job-free next week, i've been saying for a long time now
that this has to be tackled differently and even layed down some thoughts
on this. I do not think this can be done in single RFC, too much things to
handle, too much things are left out, many things are ignored by the RFC
people.

What we need, is a MANAGER! To manage the Type Hint development. And one
that is not doing real development on PHP core, but someone with
understanding.
I can offer myself at this point. I do not really care if thouse would be
strict or coercive type hints as long as it's not the dual mode stuff.

Re: [PHP-DEV] Voting irregularities

2015-03-15 Thread Arvids Godjuks

2015-03-15 20:55 GMT+02:00 Levi Morrison le...@php.net:

  What we need, is a MANAGER! To manage the Type Hint development. And one
  that is not doing real development on PHP core, but someone with
  understanding.

 You are basically saying we should hand development of a critical
 language feature over to someone not doing real development on the
 language. I don't see how that could possibly end well.

I'm saying you need a manager to orginize the process, and as I see it,
make it a multi-version effort, like the OOP has evolved. Well, I probably
over-generalized. It has to be atleast a userland developer with good
amount of PHP development experiense under his/her belt to understand, he
needs to have patiense, and above all, he needs to discipline himself on
amount of writing and replying, otherwise it will get messy again. It can
be a core dev too, it's just from what I have seen, people push their own
agenda too much when they are the developer behind the RFC. It's good over
all, but I think this paticular case is an exception.

And based on how long the type hints are taking to get anywhere, I say it
needs some special handling.

Type hints mutated over time from a simple proposal into something big,
over-engeneered and over-agressive. I have never seen a feature so complex
being done in a single go into PHP since i'm folowing internals list, and
that's since late days of PHP4...

So, long story short: I suggest we restructure the effort and have someone
impartial at the helm mediating the work being done, draw some lines and
execute a plan people can agreee on.

Re: [PHP-DEV] Voting irregularities

2015-03-15 Thread Thomas Bley

 Which post says that we're turning PHP into Java

I think there are people who want to switch from Java to PHP, maybe they feel 
easier with declare(strict...).
Also in the past, some companies switched from PHP to Java because they wanted 
more strictness in their backend code.

I don't like declare(strict...), but we should give it a chance in practice and 
then every userland developer can decide on his own if his programming style 
fits to it, or not.
For me personally, I must admit that I am not using namespaces, traits and 
goto, but almost all other features of PHP :)

Regards
Thomas


Derick Rethans wrote on 15.03.2015 20:07:

 Rowan Collins rowan.coll...@gmail.com schreef op 15 maart 2015 17:59:17
 GMT+00:00:
On 15/03/2015 14:19, Anthony Ferrara wrote:
 All,

 I ran some numbers on the current votes of the dual-mode vote right
 now. There were a number of voters that I didn't recognize. So I
 decided to pull some stats.

 The following voters never voted before the dual-mode RFC went up:

 dom - no
 eliw - no
 kguest - yes
 kk - no
 nohn - no
 oliver - yes
 richsage - yes
 sammywg - no
 spriebsch - no
 srain - no
 theseer - no
 zimt - no

 Some of these names I recognize from list (sammywg and eliw), but
many I do not.

 The interesting thing happens when you look at the voting direction.

 Currently, the RFC is slightly losing 70:37 (65.4%).

 If we look at percentages, 4.2% of yes voters have never voted in a
 prior RFC. But a whopping 24.3% of no voters have never voted before.

I think calling this an irregularity is going a bit far. 
 I don't think it's going to far, if you have people with no clue writing this:
 
 https://plus.google.com/+KristianK%C3%B6hntopp/posts/ijoDNH2M8mB
 
 Which post says that we're turning PHP into Java. And to this misguided FUD
 post, that actively asks people to vote no, I can quite easily attribute a few
 more no votes of people that had never voted before...
 
 Too late to tighten up the rules for this one, but something is definitely not
 right with the current process.
 
 Cheers,
 Derick
 -- 
 http://derickrethans.nl | http://xdebug.org
 twitter: @derickr and @xdebug
 
 -- 
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php
 


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

Re: [PHP-DEV] Voting irregularities

2015-03-15 Thread Stelian Mocanita

Can we please stop with this? It's damaging to the language and the
community.

I am a strong believer of STH, no surprise there, but I do not think this
thread should have
been created. Is the php voting process uncontrolled and chaotic with no
real count of voting
members? Hell yes.

This does not mean by far that this is the right time to discuss this. Let
the RFCs go their way
and once feature freeze is in and no more RFCs popping up for a while, the
process can be
discussed and optimised, if the case may be.

All in all STH has turned into this big charade, and no matter which way it
goes someone, there
are going to be a lot of future friction and told you so's.

In terms of managers, we do have a release manager, stick to that for the
7.0 release, re-evaluate
after.

My 2 cents,
Stelian

On Sun, Mar 15, 2015 at 8:56 PM, Thomas Bley ma...@thomasbley.de wrote:

  Which post says that we're turning PHP into Java

 I think there are people who want to switch from Java to PHP, maybe they
 feel easier with declare(strict...).
 Also in the past, some companies switched from PHP to Java because they
 wanted more strictness in their backend code.

 I don't like declare(strict...), but we should give it a chance in
 practice and then every userland developer can decide on his own if his
 programming style fits to it, or not.
 For me personally, I must admit that I am not using namespaces, traits and
 goto, but almost all other features of PHP :)

 Regards
 Thomas


 Derick Rethans wrote on 15.03.2015 20:07:

  Rowan Collins rowan.coll...@gmail.com schreef op 15 maart 2015
 17:59:17
  GMT+00:00:
 On 15/03/2015 14:19, Anthony Ferrara wrote:
  All,
 
  I ran some numbers on the current votes of the dual-mode vote right
  now. There were a number of voters that I didn't recognize. So I
  decided to pull some stats.
 
  The following voters never voted before the dual-mode RFC went up:
 
  dom - no
  eliw - no
  kguest - yes
  kk - no
  nohn - no
  oliver - yes
  richsage - yes
  sammywg - no
  spriebsch - no
  srain - no
  theseer - no
  zimt - no
 
  Some of these names I recognize from list (sammywg and eliw), but
 many I do not.
 
  The interesting thing happens when you look at the voting direction.
 
  Currently, the RFC is slightly losing 70:37 (65.4%).
 
  If we look at percentages, 4.2% of yes voters have never voted in a
  prior RFC. But a whopping 24.3% of no voters have never voted before.
 
 I think calling this an irregularity is going a bit far.
  I don't think it's going to far, if you have people with no clue writing
 this:
 
  https://plus.google.com/+KristianK%C3%B6hntopp/posts/ijoDNH2M8mB
 
  Which post says that we're turning PHP into Java. And to this misguided
 FUD
  post, that actively asks people to vote no, I can quite easily attribute
 a few
  more no votes of people that had never voted before...
 
  Too late to tighten up the rules for this one, but something is
 definitely not
  right with the current process.
 
  Cheers,
  Derick
  --
  http://derickrethans.nl | http://xdebug.org
  twitter: @derickr and @xdebug
 
  --
  PHP Internals - PHP Runtime Development Mailing List
  To unsubscribe, visit: http://www.php.net/unsub.php
 


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

Re: [PHP-DEV] Voting irregularities

2015-03-15 Thread Peter Petermann

Hi Anthony,

I am zimt.

And yes, you are correct, i haven't voted before, infact, I've kept myself
out of all discussions for a long time - for my own reasons,
however after reading into your proposal, the discussion around it, I made
the decision to cast a vote against your RFC.

You can't just throw votes away because that person never voted before,
that would be exclude everyone who has never voted before.
If that practise was applied to all RFC, well you'd end up with only those
people to vote who voted between the introduction of voting and now.
If you start picking where to apply which vote, then you start fixing the
votes to your likings, and thats not how it is supposed to work.

If you think it raises a question about voting practises, then please state
the question, because saying one thing and then saying
i'm not saying doesn't lead anywhere. And if this is really about the
voting practise, why is the numbers on what it would do with your RFC to
ignore the oldtimers relevant?

regards,
Peter Petermann



2015-03-15 15:19 GMT+01:00 Anthony Ferrara ircmax...@gmail.com:

 All,

 I ran some numbers on the current votes of the dual-mode vote right
 now. There were a number of voters that I didn't recognize. So I
 decided to pull some stats.

 The following voters never voted before the dual-mode RFC went up:

 dom - no
 eliw - no
 kguest - yes
 kk - no
 nohn - no
 oliver - yes
 richsage - yes
 sammywg - no
 spriebsch - no
 srain - no
 theseer - no
 zimt - no

 Some of these names I recognize from list (sammywg and eliw), but many I
 do not.

 The interesting thing happens when you look at the voting direction.

 Currently, the RFC is slightly losing 70:37 (65.4%).

 If we look at percentages, 4.2% of yes voters have never voted in a
 prior RFC. But a whopping 24.3% of no voters have never voted before.

 If we adjust the votes to remove these never voted accounts, it
 stands at 67:28. Which is 70.5%. Which is basically where the vote was
 prior to the competing RFC opening.

 I'm not saying that all of these are bad votes. Nor that they
 shouldn't be counted. I think it does raise a significant question
 around the voting practices.

 Something that I think we need to discuss as a group.

 So consider that discussion open.

 Anthony

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




-- 
Peter Petermann
Email: ppeterman...@gmail.com - get my public PGP key from SKS Keyservers
PGP Key:
http://pool.sks-keyservers.net:11371/pks/lookup?op=getsearch=0x0E6DBD675836A5C7

RE: [PHP-DEV] Voting irregularities

 I don't think it's going to far, if you have people with no clue writing
 this:

 https://plus.google.com/+KristianK%C3%B6hntopp/posts/ijoDNH2M8mB

Derick,

Do you know who Kristian is and how instrumental he was in the proliferation
of PHP?  How can you bring yourself to say he has no clue?  It's fine that
you disagree with him, but saying he has no clue is offensive.

Let's also not pretend there hasn't been countless calls by the RFC
supporters to vote Yes, including ones that pretend there's no problem here
and it's good for everyone.  If Kristian's position is FUD, so is that.

Zeev

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

Re: [PHP-DEV] Voting irregularities

2015-03-15 Thread Matthew Leverton

On Sun, Mar 15, 2015 at 9:19 AM, Anthony Ferrara ircmax...@gmail.com wrote:
 All,

 I ran some numbers on the current votes of the dual-mode vote right
 now. There were a number of voters that I didn't recognize. So I
 decided to pull some stats.

...

 Something that I think we need to discuss as a group.

 So consider that discussion open.

I think this is likely because the votes are made public during voting
phase. To me, that is a bad thing. It makes for an ugly voting period.
That sort of politics should happen during the discussion phase.

So I don't think there's anything wrong with first time voters
voting No en masse here. I just think there's a major problem in
having a real-time count of votes during the voting period.

If votes weren't made public during the voting, then more people would
vote on more issues... avoiding this situation where people come from
nowhere to cast a vote as word gets out on blogs that something
terrible is about to happen.

In short, I think the real-time public vote results causes a few problems:

1) Bandwagon voting, or vote for the winner mindset. The early wave
of voters can impact the results by discouraging people from voting.
(Look at Zeev's RFC vote count vs Anthony's.)
2) The losing side feverishly drumming up votes, often with scare
tactics - i.e., vocal minority. (It's much easier for the No side of
any vote to appeal to this.)
3) In rare cases, Gaming the system - closing the vote at the exact
time that benefits the owner of the RFC.

So I don't think there's anything sinister here. It's just the natural
result of the voting rules.

--
Matthew Leverton

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

Re: [PHP-DEV] Voting irregularities

2015-03-15 Thread Wim Godden



On 15/03/2015 20:30, Zeev Suraski wrote:

I don't think it's going to far, if you have people with no clue writing
this:

https://plus.google.com/+KristianK%C3%B6hntopp/posts/ijoDNH2M8mB


Do you know who Kristian is and how instrumental he was in the proliferation
of PHP?  How can you bring yourself to say he has no clue?  It's fine that
you disagree with him, but saying he has no clue is offensive.

Let's also not pretend there hasn't been countless calls by the RFC
supporters to vote Yes, including ones that pretend there's no problem here
and it's good for everyone.  If Kristian's position is FUD, so is that.



Zeev,

I agree that Kristian might have played a part in the proliferation of 
PHP,  but shouldn't we consider not only creating a clearer set of 
guidelines as to who receives voting karma, but also what the conditions 
are for keeping voting karma ? Otherwise in 10 years time we'll have 250 
people with voting karma, 150 of them for writing documentation or 
submitting a single patch 20 years ago.
If at that point a critical RFC requires voting, those 150 people could 
seriously skew the result and their votes would in some cases be 
completely opposite to what the majority of active users would want.


Maybe this is a good topic for an unconference round table discussion at 
one of the next conferences...


Just my 2 non-karma cents...

Wim

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

Re: [PHP-DEV] Voting irregularities

2015-03-15 Thread Rowan Collins


On 15/03/2015 19:07, Derick Rethans wrote:

Rowan Collins rowan.coll...@gmail.com schreef op 15 maart 2015 17:59:17 
GMT+00:00:

On 15/03/2015 14:19, Anthony Ferrara wrote:

All,

I ran some numbers on the current votes of the dual-mode vote right
now. There were a number of voters that I didn't recognize. So I
decided to pull some stats.

The following voters never voted before the dual-mode RFC went up:

dom - no
eliw - no
kguest - yes
kk - no
nohn - no
oliver - yes
richsage - yes
sammywg - no
spriebsch - no
srain - no
theseer - no
zimt - no

Some of these names I recognize from list (sammywg and eliw), but

many I do not.

The interesting thing happens when you look at the voting direction.

Currently, the RFC is slightly losing 70:37 (65.4%).

If we look at percentages, 4.2% of yes voters have never voted in a
prior RFC. But a whopping 24.3% of no voters have never voted before.

I think calling this an irregularity is going a bit far.

I don't think it's going to far, if you have people with no clue writing this:

https://plus.google.com/+KristianK%C3%B6hntopp/posts/ijoDNH2M8mB


What I said was going too far was pointing at a cherry-picked statistic 
and calling it voting irregularities. That has nothing to do with 
people's motivations for voting, and whether they were well-founded.


It's not an irregularity when far-right politicians get voted into 
power, however misguided I may feel the voters were; it's simply a 
result of holding an election in the first place. Ultimately, you can 
either give people the right to participate and accept they may act 
unwisely, or you can appoint an unchallengable meritocracy and accept 
that they may act unpopularly.


That's not to say that voting reform can't be considered - at, as Zeev 
says, an appropriate time - but that the rules should be based on 
principles of fairness, not analysis of how past votes would have turned 
out.


Regards,

--
Rowan Collins
[IMSoP]


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

Re: [PHP-DEV] Voting irregularities

Hi!

 voting practices. Anthony specifically notes that he is not calling
 them bad, or calling for them to be ignored in the context of the

He's not calling them bad directly, he is calling them irregularities,
singling them out and arguing that they are the reason the RFC is
currently does not have necessary majority, and also specifically says
not _all_ of them bad, implying at least some of them are. It's as
close to calling them bad as you can go while still having that out
that he didn't say it directly. It's like saying I'm not saying X is a
complete crook but look at a long list of arguments which is intended
to make everybody think X is a crook.

 current RFCs. Merely noting that their existence has skewed this
 particular vote, as a recent ongoing example, which it has. I have to

Everybody's vote has skewed this particular vote, by mere fact of
voting. So far we had many votes, in which many people voted, I have no
idea which of them voted for the first time when, still none of these
results were questioned for a reason that votes of people voting for the
first time or rarely is an irregularity. Suddenly, when a particularly
controversial vote is going on, it is a problem. I do not consider it
healthy.

In other, more opportune and less controversial, time, with different
example at stake, this could be a useful discussion, though even then
I'd prefer not to start it with singling people out but with
establishing general principles and goals we want to achieve with this.
-- 
Stas Malyshev
smalys...@gmail.com

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

RE: [PHP-DEV] Voting irregularities

 -Original Message-
 From: Wim Godden [mailto:wim.god...@cu.be]
 Sent: Sunday, March 15, 2015 11:30 PM
 To: Zeev Suraski
 Cc: internals@lists.php.net
 Subject: Re: [PHP-DEV] Voting irregularities

 On 15/03/2015 20:30, Zeev Suraski wrote:
  I don't think it's going to far, if you have people with no clue
  writing
  this:

  https://plus.google.com/+KristianK%C3%B6hntopp/posts/ijoDNH2M8mB

  Do you know who Kristian is and how instrumental he was in the
  proliferation of PHP?  How can you bring yourself to say he has no
  clue?  It's fine that you disagree with him, but saying he has no clue
  is
 offensive.

  Let's also not pretend there hasn't been countless calls by the RFC
  supporters to vote Yes, including ones that pretend there's no problem
  here and it's good for everyone.  If Kristian's position is FUD, so is
  that.

 Zeev,

 I agree that Kristian might have played a part in the proliferation of
 PHP,  but
 shouldn't we consider not only creating a clearer set of guidelines as to
 who
 receives voting karma, but also what the conditions are for keeping voting
 karma ? Otherwise in 10 years time we'll have 250 people with voting
 karma,
 150 of them for writing documentation or submitting a single patch 20
 years
 ago.

Any discussion about who gets to vote should be done after we're done voting
and not right now.  The quiet period after the PHP 7.0 votes are over would
probably be good for that.

Zeev

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

Re: [PHP-DEV] Voting irregularities

Hi!

 Which post says that we're turning PHP into Java. And to this
 misguided FUD post, that actively asks people to vote no, I can quite
 easily attribute a few more no votes of people that had never voted
 before...

I have seen many messages on the list which I personally consider very
wrong and/or misguided, and that called to vote yes. And I can, if I'd
like to, attribute significant number of yes votes to it (of course, the
true answer is I have no idea if it's so or not, but neither do you,
right?). Does it mean those votes are invalid? Does it mean I can pick
and choose yes votes I dislike and throw them out (I'd even include 1/4
of opposite votes just like it was done in topic-starting message, for
fairness :) I don't think that would be a healthy process, do you?

 Too late to tighten up the rules for this one, but something is
 definitely not right with the current process.

OK, what do you offer to improve it? Restrict who can vote? How? Allow
votes only to people that are well-informed? How do you distinguish
well informed from agrees with me? So far I don't think solution for
this issue has been ever found, even when the stakes are much much
higher than strict typing in PHP, but if you have a solution it would
certainly be interesting to hear it.
-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] Voting irregularities

2015-03-15 Thread Dennis Birkholz

Hi all,

Am 15.03.2015 um 15:19 schrieb Anthony Ferrara:
 ... There were a number of voters that I didn't recognize.

I wondered about who the people are that vote and how they earned the
right to do so. I think this kind of confusion could be avoided if
people.php.net would contain a little more information. Each profile
should contain the reason why the person got the voting karma granted
(and when maybe). Then you don't stumble over empty profile pages and
this kind of discussion is solved until someone bothers to propose an
RFC to change voting rules.

Thanks for listening
Dennis

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

Re: [PHP-DEV] Voting irregularities

2015-03-15 Thread Jordi Boggiano


On 15/03/2015 22:27, Derick Rethans wrote:

On Sun, 15 Mar 2015, Zeev Suraski wrote:


I don't think it's going to far, if you have people with no clue writing
this:

https://plus.google.com/+KristianK%C3%B6hntopp/posts/ijoDNH2M8mB


Do you know who Kristian is and how instrumental he was in the
proliferation of PHP?  How can you bring yourself to say he has no
clue?


I certainly know who he is. I've been around as nearly as long as you've
been. Anybody who's only argument is You're turning PHP into Java and
basically says we need four more against votes has no clue. I don't
care who says it.


I agree that past good deeds and contributions should not be a free pass 
for bad behavior. Not going to discuss the example at hand, but I think 
it's dangerous to say it's ok he did good in the past.


Cheers
Jordi

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

Re: [PHP-DEV] Voting irregularities

2015-03-15 Thread Pádraic Brady

Hi,

On 15 March 2015 at 14:19, Anthony Ferrara ircmax...@gmail.com wrote:
 I'm not saying that all of these are bad votes. Nor that they
 shouldn't be counted. I think it does raise a significant question
 around the voting practices.

I think folk should be cautious about linking the proximity of a
certain RFC to this topic. It appears to be leading to conspiracy
theory cries despite Anthony's statement above. As I've already
indicated, and being a Yes voter, I'm sort of dubious about even my
own voting rights, and votes of my nature have previously been called
out as a bad thing by people on both sides of the RFC.

As such, there does appear to be a debate to be had. The timing may be
unfortunate, given the sensitivity around the scalar type RFCs, but
that doesn't remove the fact that the debate should be had if it's
going to be dumped onto Twitter and other threads by other people who
are not called Anthony ;).

As to whether the quoted data suggests suspicious activities: no. The
pool of voters is tiny and no trends or conclusions can be drawn, and
the number of votes shows that the RFCs have attracted immense
attention which would attract erstwhile non-voters which might easily
warp the expected result of any vote simply by them exercising their
vote unexpectedly. The concern around handing out votes too freely
still exists, and I respect that. From the responses thus far, others
have declined to exercise or restrict their votes so we do have
issues to resolve in making it absolutely clear who may or may not
vote without feeling some sense of guilt or inviting comment when the
vote count reaches for the sky and those like me come out of the
woodwork ;).

Paddy

--
Pádraic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com

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

Re: [PHP-DEV] Voting irregularities

2015-03-15 Thread Pierre Joye

On Mon, Mar 16, 2015 at 10:08 AM, Jordi Boggiano j.boggi...@seld.be wrote:
 On 15/03/2015 22:27, Derick Rethans wrote:

 On Sun, 15 Mar 2015, Zeev Suraski wrote:

 I don't think it's going to far, if you have people with no clue writing
 this:

 https://plus.google.com/+KristianK%C3%B6hntopp/posts/ijoDNH2M8mB


 Do you know who Kristian is and how instrumental he was in the
 proliferation of PHP?  How can you bring yourself to say he has no
 clue?


 I certainly know who he is. I've been around as nearly as long as you've
 been. Anybody who's only argument is You're turning PHP into Java and
 basically says we need four more against votes has no clue. I don't
 care who says it.


 I agree that past good deeds and contributions should not be a free pass for
 bad behavior. Not going to discuss the example at hand, but I think it's
 dangerous to say it's ok he did good in the past.

I cannot agree more. I deeply respect Kristian, in all possible manners.

However, I never call to vote for a given RFC but state what I think
and let people make their own choice. Big names, all relative, have a
social responsibility when it comes to ask people to vote for or
against a given features. Big names backed by companies even more,
even if something is done on a private manner. We have to be extremely
careful on that. And we include myself.

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

Hi!

 So consider that discussion open.

I guess this would have to happen sooner or later - sooner or later
somebody, when the vote doesn't go their way, would cry who are all
these people? It can't be right they are all legit, there must be
something wrong. I'm not sure though where this discussion is supposed
to lead. What outcome should it produce? OK, you have singled out 12
people (some I recognize, some I do not, which means nothing except
probably my memory is bad or I haven't met them) and called their votes
irregularity. I know if you did that to me I'd be annoyed, but of
course they don't have to think like I do.
Still, I don't see where this is going - are we to question or reject
every vote from a person that votes rarely? Are we to institute stricter
rules for who gets a vote, and if so, which ones? Are we just to throw
out votes because RFC author doesn't accept them and without them the
RFC passes and is it going to be a normal process for us from now on?

Discussion of such sort, especially while singling out people for
exclusion, is very dangerous and should be done very carefully. Even
when not connected to a controversial topic and is bound to change the
resulting outcome. When it does, I'm not sure it's a good place and time
to start it at all.
-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] Voting irregularities

Hi!

 theory cries despite Anthony's statement above. As I've already
 indicated, and being a Yes voter, I'm sort of dubious about even my
 own voting rights, and votes of my nature have previously been called
 out as a bad thing by people on both sides of the RFC.

If you think you're not informed enough or not in position, or don't
have opinion about something - it's ok not to vote, it's not mandatory
:) Of course, now not voting is declared suspicious so who knows, but
there's absolutely no shame in abstaining if one doesn't feel ready to
take a position. Having the opportunity to vote, of course, is quite a
different matter.

On a more broad note, if people are really dissatisfied with voting,
let's look for alternatives. But I personally would like to see a bit
more of a positive program. I mean, ok, voting is not good as currently
done. So who you think should be voting? Only engine committers? Only
PHP source committers? Only Chosen People, chosen by TBD process? Or
should we get rid of voting and do what instead?
I am far from claiming current process is ideal, and I had my deal of
frustrations by it. But so far I don't see anything that would be
clearly better, both from process and from legitimacy side. Do you?
-- 
Stas Malyshev
smalys...@gmail.com

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

RE: [PHP-DEV] Voting irregularities

2015-03-15 Thread Derick Rethans

On Sun, 15 Mar 2015, Zeev Suraski wrote:

  I don't think it's going to far, if you have people with no clue writing
  this:
 
  https://plus.google.com/+KristianK%C3%B6hntopp/posts/ijoDNH2M8mB
 
 Do you know who Kristian is and how instrumental he was in the 
 proliferation of PHP?  How can you bring yourself to say he has no 
 clue?

I certainly know who he is. I've been around as nearly as long as you've 
been. Anybody who's only argument is You're turning PHP into Java and 
basically says we need four more against votes has no clue. I don't 
care who says it.

cheers,
Derick

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

Re: [PHP-DEV] Voting irregularities

2015-03-15 Thread Philip Sturgeon

One rule I liked when I was part of the FIG was that people can only
vote on votes initiated after they became a member. That stops people
signing up simply to vote on an RFC which needs more votes either way.

I'm not saying that happened, but a simple rule saying You cannot
vote on any RFC started before you signed up should not be considered
controversial by anyone.

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

Re: [PHP-DEV] Voting choice for language changes (Was: Re: [PHP-DEV][RFC][DISCUSSION] Strict Argument Count)

2015-03-12 Thread Dan Ackroyd

On 10 March 2015 at 15:02, Anthony Ferrara ircmax...@gmail.com wrote:

 Can we please come down to a single RFC, with a single vote yes/no?
 It's easier to understand, easier to manage and has less possibility
 of gaming.


While I generally agree, in the case where there is a small detail
that needs to be addresses by a vote, I think having two votes in one
RFC is better than having two almost identical RFCs.

However the question that is being voted on needs to be setup properly
so that it does not prevent people from being able to vote on both
issues.

For example the group use RFC
(https://wiki.php.net/rfc/group_use_declarations) has a small detail
of whether there should be a trailing slash in the syntax, which did
not deserve a separate RFC imo.

Unfortunately, the vote options were:
- Yes - with a trailing \
- Yes - without a trailing \
- No

This meant it was impossible for people who wanted to vote no to the
general idea, to say what was their preferred choice of syntax. The
questions and voting choices should have been:

 Should Grouped Use Declarations be added to PHP 7
- Yes
- No

If added, should the syntax be with trailing \ or without.
- With a trailing \
- Without a trailing \

This would have allowed all voters to express their intent for both
parts of the question, without being forced to vote 'yes' if they want
a say in the exact syntax used.

cheers
Dan
Ack

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

Re: [PHP-DEV] Voting choice for language changes (Was: Re: [PHP-DEV][RFC][DISCUSSION] Strict Argument Count)

2015-03-12 Thread Derick Rethans

On Tue, 10 Mar 2015, Patrick ALLAERT wrote:

 2015-03-10 16:02 GMT+01:00 Anthony Ferrara ircmax...@gmail.com:
 
  Can we please come down to a single RFC, with a single vote yes/no?
  It's easier to understand, easier to manage and has less possibility
  of gaming.
 
 That is much more stricter than my thoughts but I can't agree more
 with you on all the points you mentioned.
 You even presented cases I had in mind, thanks for the verbosity :)

+1

 We should probably add this to https://wiki.php.net/rfc/voting which 
 should probably RFC'ed...

I think you just volunteerd ;-)

cheers,
Derick

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

[PHP-DEV] Voting choice for language changes (Was: Re: [PHP-DEV][RFC][DISCUSSION] Strict Argument Count)

2015-03-10 Thread Patrick ALLAERT

Hello,

Le ven. 6 mars 2015 à 00:44, Marcio Almada marcio.w...@gmail.com a écrit :

 You are right about this. I'll setup a yes/no vote + a vote to decide
 between E_WARNING (for consistency), E_DEPRECATED or E_STRICT. For me this
 is just a detail but maybe it's very important to others, so better to let
 each voter decide upon it.


In case of language changes, shouldn't the 2/3 of majority be required at
any levels?

In situations like:

Main feature: No/Yes
Option: A, B or C

My gut feeling is that it would be better to rally a 2/3 majority of people
behind one of:
No / Yes (A) / Yes (B) / Yes (C)
in order to not dilute the importance of language changes.

It would prevent accepting an important change where a lot of people agrees
on a general idea but have strong opinions/arguments on
implementation/details.

Cheers,
Patrick

Re: [PHP-DEV] Voting choice for language changes (Was: Re: [PHP-DEV][RFC][DISCUSSION] Strict Argument Count)

2015-03-10 Thread Anthony Ferrara

Patrick,

My viewpoint is that options in an RFC are dangerous. I would much
rather have a single RFC, with a single vote (yes/no). I think we
should be discouraging the options as much as possible.

The reason is simple: an RFC should be an encapsulated idea, not a
menu of options. The author should take a stance. If there are details
that the author can't decide on, then either take a straw poll in the
mailing list, or create a separate RFC for that option.

The problem with options is that it makes the vote much more
confusing. With 3 options, you have 3 different proposals. Some recent
votes have had upwards of 12 different proposals built in to a single
RFC (2 options + 3 options + 2 options). It's enough to ask someone to
read and understand one proposal completely without having them have
to comprehend all the possible permutations of voting outcomes.

It also encourages weird voting patterns. Take your example of No/Yes,
A/B/C. In that case, you have 4 permutations as you pointed out. But
what's deeper, is how should someone vote if they are opposed to B? I
mean opposed, not just preferring a different one? The tendency would
likely be to watch the vote and if it looks like B will pass, vote no
on the entire proposal.

Can we please come down to a single RFC, with a single vote yes/no?
It's easier to understand, easier to manage and has less possibility
of gaming.

Anthony

On Tue, Mar 10, 2015 at 10:39 AM, Patrick ALLAERT
patrickalla...@php.net wrote:
 Hello,

 Le ven. 6 mars 2015 à 00:44, Marcio Almada marcio.w...@gmail.com a écrit :

 You are right about this. I'll setup a yes/no vote + a vote to decide
 between E_WARNING (for consistency), E_DEPRECATED or E_STRICT. For me this
 is just a detail but maybe it's very important to others, so better to let
 each voter decide upon it.


 In case of language changes, shouldn't the 2/3 of majority be required at
 any levels?

 In situations like:

 Main feature: No/Yes
 Option: A, B or C

 My gut feeling is that it would be better to rally a 2/3 majority of people
 behind one of:
 No / Yes (A) / Yes (B) / Yes (C)
 in order to not dilute the importance of language changes.

 It would prevent accepting an important change where a lot of people agrees
 on a general idea but have strong opinions/arguments on
 implementation/details.

 Cheers,
 Patrick

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

Re: [PHP-DEV] Voting choice for language changes (Was: Re: [PHP-DEV][RFC][DISCUSSION] Strict Argument Count)

2015-03-10 Thread Marcio Almada

2015-03-10 13:52 GMT-03:00 Anthony Ferrara ircmax...@gmail.com:

 Dan,

 On Tue, Mar 10, 2015 at 11:45 AM, Dan Ackroyd dan...@basereality.com
 wrote:
  On 10 March 2015 at 15:02, Anthony Ferrara ircmax...@gmail.com wrote:
 
  Can we please come down to a single RFC, with a single vote yes/no?
  It's easier to understand, easier to manage and has less possibility
  of gaming.
 
 
  While I generally agree, in the case where there is a small detail
  that needs to be addresses by a vote, I think having two votes in one
  RFC is better than having two almost identical RFCs.
 
  However the question that is being voted on needs to be setup properly
  so that it does not prevent people from being able to vote on both
  issues.
 
  For example the group use RFC
  (https://wiki.php.net/rfc/group_use_declarations) has a small detail
  of whether there should be a trailing slash in the syntax, which did
  not deserve a separate RFC imo.
 
  Unfortunately, the vote options were:
  - Yes - with a trailing \
  - Yes - without a trailing \
  - No

 In this case, a straw-poll ahead of time for with or without could
 have solved that. Or just choosing one.

 But in more complex situations it doesn't need to be competing RFCs,
 but a RFC for the main thing, and a RFC to choose which option. This
 case (with/without \) isn't what I was referring to. I was talking
 more about situations like:


 https://wiki.php.net/rfc/error_handler_callback_parameters_passed_by_reference#vote

 Specifically where the options have pretty significant difference in
 potential functionality.

 https://wiki.php.net/rfc/pecl_http#vote

 Here, enabled/disabled by default, and the namespace?

 The namespace is a pretty significant concern. I believe that the RFC
 should have taken a stance on it. But if it didn't want to, it could
 split it off into its own proposal. So you'd have RFC#1: add pecl_http
 to core, and RFC#2: change pecl_http to use the php\ namespace prefix.

 By splitting it apart it's a lot clearer what's going on, and the
 impact of the decision can be weighed.

 If I was doing the proposal though, I would make a single RFC that
 takes a stance (picks one). Then let the discussion guide the change.
 If people really feel that another option is better, it will become
 clear, so the RFC can be updated.  That's the point of discussion, no?


Yes, that is the point of discussion. But, unfortunately, a lot of RFCs
only start to get discussed when the voting is open. I don't know why this
happens, but it's a pattern I've been observing for some time. In general,
I agree with you, we should make some effort to eliminate voting options
during discussion phase, or at least reduce the options to a minimum amount.


 Anthony

Re: [PHP-DEV] Voting choice for language changes (Was: Re: [PHP-DEV][RFC][DISCUSSION] Strict Argument Count)

2015-03-10 Thread Anthony Ferrara

Dan,

On Tue, Mar 10, 2015 at 11:45 AM, Dan Ackroyd dan...@basereality.com wrote:
 On 10 March 2015 at 15:02, Anthony Ferrara ircmax...@gmail.com wrote:

 Can we please come down to a single RFC, with a single vote yes/no?
 It's easier to understand, easier to manage and has less possibility
 of gaming.


 While I generally agree, in the case where there is a small detail
 that needs to be addresses by a vote, I think having two votes in one
 RFC is better than having two almost identical RFCs.

 However the question that is being voted on needs to be setup properly
 so that it does not prevent people from being able to vote on both
 issues.

 For example the group use RFC
 (https://wiki.php.net/rfc/group_use_declarations) has a small detail
 of whether there should be a trailing slash in the syntax, which did
 not deserve a separate RFC imo.

 Unfortunately, the vote options were:
 - Yes - with a trailing \
 - Yes - without a trailing \
 - No

In this case, a straw-poll ahead of time for with or without could
have solved that. Or just choosing one.

But in more complex situations it doesn't need to be competing RFCs,
but a RFC for the main thing, and a RFC to choose which option. This
case (with/without \) isn't what I was referring to. I was talking
more about situations like:

https://wiki.php.net/rfc/error_handler_callback_parameters_passed_by_reference#vote

Specifically where the options have pretty significant difference in
potential functionality.

https://wiki.php.net/rfc/pecl_http#vote

Here, enabled/disabled by default, and the namespace?

The namespace is a pretty significant concern. I believe that the RFC
should have taken a stance on it. But if it didn't want to, it could
split it off into its own proposal. So you'd have RFC#1: add pecl_http
to core, and RFC#2: change pecl_http to use the php\ namespace prefix.

By splitting it apart it's a lot clearer what's going on, and the
impact of the decision can be weighed.

If I was doing the proposal though, I would make a single RFC that
takes a stance (picks one). Then let the discussion guide the change.
If people really feel that another option is better, it will become
clear, so the RFC can be updated.  That's the point of discussion, no?

Anthony

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

Re: [PHP-DEV] Voting choice for language changes (Was: Re: [PHP-DEV][RFC][DISCUSSION] Strict Argument Count)

2015-03-10 Thread Patrick ALLAERT

2015-03-10 16:02 GMT+01:00 Anthony Ferrara ircmax...@gmail.com:
 Patrick,

 My viewpoint is that options in an RFC are dangerous. I would much
 rather have a single RFC, with a single vote (yes/no). I think we
 should be discouraging the options as much as possible.

 The reason is simple: an RFC should be an encapsulated idea, not a
 menu of options. The author should take a stance. If there are details
 that the author can't decide on, then either take a straw poll in the
 mailing list, or create a separate RFC for that option.

 The problem with options is that it makes the vote much more
 confusing. With 3 options, you have 3 different proposals. Some recent
 votes have had upwards of 12 different proposals built in to a single
 RFC (2 options + 3 options + 2 options). It's enough to ask someone to
 read and understand one proposal completely without having them have
 to comprehend all the possible permutations of voting outcomes.

 It also encourages weird voting patterns. Take your example of No/Yes,
 A/B/C. In that case, you have 4 permutations as you pointed out. But
 what's deeper, is how should someone vote if they are opposed to B? I
 mean opposed, not just preferring a different one? The tendency would
 likely be to watch the vote and if it looks like B will pass, vote no
 on the entire proposal.

 Can we please come down to a single RFC, with a single vote yes/no?
 It's easier to understand, easier to manage and has less possibility
 of gaming.

 Anthony

That is much more stricter than my thoughts but I can't agree more
with you on all the points you mentioned.
You even presented cases I had in mind, thanks for the verbosity :)

We should probably add this to https://wiki.php.net/rfc/voting which
should probably RFC'ed...

Thanks!

Patrick

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

Re: [PHP-DEV] Voting choice for language changes (Was: Re: [PHP-DEV][RFC][DISCUSSION] Strict Argument Count)

2015-03-10 Thread Marcio Almada

Hi,

2015-03-10 12:45 GMT-03:00 Dan Ackroyd dan...@basereality.com:

 On 10 March 2015 at 15:02, Anthony Ferrara ircmax...@gmail.com wrote:
 
  Can we please come down to a single RFC, with a single vote yes/no?
  It's easier to understand, easier to manage and has less possibility
  of gaming.


 While I generally agree, in the case where there is a small detail
 that needs to be addresses by a vote, I think having two votes in one
 RFC is better than having two almost identical RFCs.

 However the question that is being voted on needs to be setup properly
 so that it does not prevent people from being able to vote on both
 issues.

 For example the group use RFC
 (https://wiki.php.net/rfc/group_use_declarations) has a small detail
 of whether there should be a trailing slash in the syntax, which did
 not deserve a separate RFC imo.

 Unfortunately, the vote options were:
 - Yes - with a trailing \
 - Yes - without a trailing \
 - No

 This meant it was impossible for people who wanted to vote no to the
 general idea, to say what was their preferred choice of syntax. The
 questions and voting choices should have been:

  Should Grouped Use Declarations be added to PHP 7
 - Yes
 - No

 If added, should the syntax be with trailing \ or without.
 - With a trailing \
 - Without a trailing \

 This would have allowed all voters to express their intent for both
 parts of the question, without being forced to vote 'yes' if they want
 a say in the exact syntax used.

 cheers
 Dan
 Ack


That's so true. The Group Use... was my first RFC and I have to admit this
voting setup was poor decision taking on my part, sorry.

Later some people even confessed that they didn't vote yes because they
haven't noticed it was necessary when in reality they just couldn't realize
they should sum the yes votes to know if the RFC was passing or not.

I'll avoid to setup a vote like this again and will always prefer the
multiple questions approach in situations where options are inevitable.

Thanks,
Márcio

Re: [PHP-DEV] Voting on PHP features

2013-03-18 Thread Florian Anderiasch

On 03/17/2013 02:12 PM, Clint Priest wrote:
 Unfortunately my experience with that process has been that many people
 will vote who had no part in the discussion.

I don't see a point repeating points of discussion when being in
agreement with people who already stated their opinion, or being
persuaded by arguments given.

I suppose the majority of voters will read the discussion, not
necessarily actively participate. At least that would be sensible, right? :)

Greetings,
Florian

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

Re: [PHP-DEV] Voting on PHP features

2013-03-18 Thread Gwynne Raskind

On Mar 18, 2013, at 5:57 AM, Florian Anderiasch m...@anderiasch.de wrote:
 On 03/17/2013 02:12 PM, Clint Priest wrote:
 Unfortunately my experience with that process has been that many people
 will vote who had no part in the discussion.
 
 I don't see a point repeating points of discussion when being in
 agreement with people who already stated their opinion, or being
 persuaded by arguments given.
 
 I suppose the majority of voters will read the discussion, not
 necessarily actively participate. At least that would be sensible, right? :)
 
 Greetings,
 Florian

I practically never participate in discussions, but I always read them before 
voting. As you say, it's just common sense.

-- Gwynne Raskind


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

Re: [PHP-DEV] Voting on PHP features

2013-03-17 Thread Clint Priest

Unfortunately my experience with that process has been that many people 
will vote who had no part in the discussion.


On 3/16/2013 3:16 PM, Sherif Ramadan wrote:

On Sat, Mar 16, 2013 at 5:28 AM, Sébastien Durand se8@gmail.com wrote:


Hi guys,

*I think it could be a nice little improvement to add an extra form field
(*160
chars max),* that would let users quickly comment on why they voted yes
or no.*
*
*
*It would help having a better sense of what's going on and** to understand
why this proposed feature is a good language design or not, without having
to review countless messages on the mailing list.*
*
*


I'm pretty sure that's the purpose of the discussion stage is before a
feature is put to a vote. The purpose of the vote should be pure and
simple. Yay or Nay.



*My two cents,*
*
*
*Sébastien*



--
-Clint

[PHP-DEV] Voting on PHP features

2013-03-16 Thread Sébastien Durand

Hi guys,

*I think it could be a nice little improvement to add an extra form field (*160
chars max),* that would let users quickly comment on why they voted yes
or no.*
*
*
*It would help having a better sense of what's going on and** to understand
why this proposed feature is a good language design or not, without having
to review countless messages on the mailing list.*
*
*
*My two cents,*
*
*
*Sébastien*

Re: [PHP-DEV] Voting on PHP features

2013-03-16 Thread Sherif Ramadan

On Sat, Mar 16, 2013 at 5:28 AM, Sébastien Durand se8@gmail.com wrote:

 Hi guys,

 *I think it could be a nice little improvement to add an extra form field
 (*160
 chars max),* that would let users quickly comment on why they voted yes
 or no.*
 *
 *
 *It would help having a better sense of what's going on and** to understand
 why this proposed feature is a good language design or not, without having
 to review countless messages on the mailing list.*
 *
 *


I'm pretty sure that's the purpose of the discussion stage is before a
feature is put to a vote. The purpose of the vote should be pure and
simple. Yay or Nay.


 *My two cents,*
 *
 *
 *Sébastien*

RE: [PHP-DEV] Voting periods

2013-01-30 Thread Attila Bukor

That's what Ralf and I suggested all along. By the way, the problem is
that most of the web developers don't know anything about IT. I guess
most of them use Windows (and you can't expect a Windows user to
compile stuff), and the majority of the other half uses Ubuntu and
never even saw the shell, they're using Ubuntu Software Centre. I'm not
talking about those who go to conferences, but the vast majority of PHP
coders who never wrote a single bit of native code and never had to
compile anything.

r1pp3rj4ck
From: Stas Malyshev
Sent: 30/01/2013 07:04
To: Larry Garfield
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Voting periods
Hi!

 down.  Right or wrong, good or bad, the gulf between PHP developer and C
 developer is *huge*, and doing anything at all with the PHP engine,

We're not talking here writing code in C. We're talking here typing
configure in shell, hitting enter, then typing make in shell, then
hitting enter. It's not really *that* hard. OK, there are all kinds of
envt problems and so on that could happen, but on standard Linux with
standard libs that's pretty much it.

But if even that is too hard, how about making something like spec file
for RPM and a script that d/ls a snapshot and then builds a RPM from it?
Installing RPM shouldn't be too hard?
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

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

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

Re: [PHP-DEV] Voting periods

2013-01-30 Thread Dan Cryer

 That's what Ralf and I suggested all along. By the way, the problem is
 that most of the web developers don't know anything about IT. I guess
 most of them use Windows (and you can't expect a Windows user to
 compile stuff), and the majority of the other half uses Ubuntu and
 never even saw the shell, they're using Ubuntu Software Centre. I'm not
 talking about those who go to conferences, but the vast majority of PHP
 coders who never wrote a single bit of native code and never had to
 compile anything.


Not meaning to sound obnoxious, but are those kind of developers really
likely to be able to give useful enough feedback that their testing nightly
builds would be valuable? Surely a developer who doesn't know how to use
the shell is going to be limited in what level of detail they can provide,
potentially making the bug fixing process significantly more difficult.

I'm no C developer, most of my work is in PHP - but I've never found it a
struggle to compile PHP, MySQL or any of their associated libraries.

Re: [PHP-DEV] Voting periods

2013-01-30 Thread Attila Bukor

Dan, I'm a PHP developer myself too and I always compile PHP and Apache for
my own (PostgreSQL is good for me as it's packaged for Archlinux). But the
majority is just dumb. And you're right about the bug reports, lots of them
would be just like it doesn't work because of reasons. But they'd at
least try and we still could extract some valuable information from that.

r1pp3rj4ck


On Wed, Jan 30, 2013 at 9:47 AM, Dan Cryer d...@dancryer.com wrote:


 That's what Ralf and I suggested all along. By the way, the problem is
 that most of the web developers don't know anything about IT. I guess
 most of them use Windows (and you can't expect a Windows user to
 compile stuff), and the majority of the other half uses Ubuntu and
 never even saw the shell, they're using Ubuntu Software Centre. I'm not
 talking about those who go to conferences, but the vast majority of PHP
 coders who never wrote a single bit of native code and never had to
 compile anything.


 Not meaning to sound obnoxious, but are those kind of developers really
 likely to be able to give useful enough feedback that their testing nightly
 builds would be valuable? Surely a developer who doesn't know how to use
 the shell is going to be limited in what level of detail they can provide,
 potentially making the bug fixing process significantly more difficult.

 I'm no C developer, most of my work is in PHP - but I've never found it a
 struggle to compile PHP, MySQL or any of their associated libraries.

Re: [PHP-DEV] Voting periods

hi Ryan,

On Tue, Jan 29, 2013 at 8:55 AM, Ryan McCue li...@rotorised.com wrote:
 Larry Garfield wrote:
 It's great to hear you say that, given that the messaging coming out of
 WP at the time was rather hostile. :-)

 As I noted, the dynamics have changed significantly. I'd say that core
 committer team as a whole is now much less conservative than before,
 although they're still just as dedicated to internal backwards
 compatibility.

It would be already very good if wp (strongly) suggests to use #php
5.3/4 instead of 5.2 on http://wordpress.org/about/requirements/ and
with a notice in the installer code.


Cheers,
--
Pierre

@pierrejoye

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

Re: [PHP-DEV] Voting periods

2013-01-29 Thread Ryan McCue

Pierre Joye wrote:
 It would be already very good if wp (strongly) suggests to use #php
 5.3/4 instead of 5.2 on http://wordpress.org/about/requirements/ and
 with a notice in the installer code.

That's a great idea, and it's something I'll definitely try and bring up
with the other developers.

-- 
Ryan McCue
http://ryanmccue.info/

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

Re: [PHP-DEV] Voting periods

hi Jan,

On Tue, Jan 29, 2013 at 11:55 AM, Jan Ehrhardt php...@ehrhardt.nl wrote:
 Hi Pierre,

 Pierre Joye in php.internals (Tue, 29 Jan 2013 05:55:27 +0100):
This is one of the reason why the 'new' release process RFC does not
allow BC breaks. But we can't be 100% sure that we do not introduce
one without you, all projects and users, doing intensive testing using
your apps, modules, plugins, etc. And before the final releases, not
after.

Question: Did you test D7/8 and their respective plugins with php 5.5?

 No. Reality: many Drupal users are beginning to move from Drupal 6 to
 Drupal 7 at the moment. So are we. The code freeze for Drupal 8 will be
 no sooner than July this year. And we have enough issues with D7 under
 PHP 5.4 to worry about BC breaks beyond PHP 5.4.

What do you need to get D7 tested under 5.5? I mean once you have a CI
in place, it is not hard to setup one instance to test 5.5.

Waiting the final release of 5.5 won't be of any help, not for Drupal,
not for us.

 Where does that leave me as of March 2014? With PHP 5.3 that is no
 longer supported by php.net and not really supported by Directadmin
 either. Limited resources on all sides...

Why we have to take choices. If you need more resources or some help
to setup testing instances for 5.5 or other, please let me know. But
waiting until 5.5 is out to begin testing is a really bad idea (by
choice or by default).

Cheers,
--
Pierre

@pierrejoye

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

Re: [PHP-DEV] Voting periods

2013-01-29 Thread Jan Ehrhardt

Pierre Joye in php.internals (Tue, 29 Jan 2013 12:08:16 +0100):
What do you need to get D7 tested under 5.5? I mean once you have a CI
in place, it is not hard to setup one instance to test 5.5.

I do not need anything, except for 48 hours in a day and some disk space
on my Win7 laptop ;-)

Waiting the final release of 5.5 won't be of any help, not for Drupal,
not for us.

Just to make things clear: I am not a Drupal developer, I develop with
Drupal. In other words: I am a D6  D7 user. I report PHP issues on
drupal.org and try to find solutions.

Jan

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

Re: [PHP-DEV] Voting periods

2013-01-29 Thread Larry Garfield


On 1/29/13 5:08 AM, Pierre Joye wrote:

hi Jan,

On Tue, Jan 29, 2013 at 11:55 AM, Jan Ehrhardt php...@ehrhardt.nl wrote:

Hi Pierre,

Pierre Joye in php.internals (Tue, 29 Jan 2013 05:55:27 +0100):

This is one of the reason why the 'new' release process RFC does not
allow BC breaks. But we can't be 100% sure that we do not introduce
one without you, all projects and users, doing intensive testing using
your apps, modules, plugins, etc. And before the final releases, not
after.

Question: Did you test D7/8 and their respective plugins with php 5.5?


No. Reality: many Drupal users are beginning to move from Drupal 6 to
Drupal 7 at the moment. So are we. The code freeze for Drupal 8 will be
no sooner than July this year. And we have enough issues with D7 under
PHP 5.4 to worry about BC breaks beyond PHP 5.4.


What do you need to get D7 tested under 5.5? I mean once you have a CI
in place, it is not hard to setup one instance to test 5.5.

Waiting the final release of 5.5 won't be of any help, not for Drupal,
not for us.


Clear, detailed instructions aimed at someone who has *never used a C 
compiler before*[1] for how to build, install, and run a 5.5 alpha, for 
Mac and for common Linuxes[2], that do not require doing screwy things 
with running multiple web servers on a single OS.  In fact, the ideal 
would be periodically released VirtualBox images with the latest alpha 
or beta tagged that we can just boot up and run.[3]


The first point is, I think, the biggest blocker.  Try out the latest 
PHP and see what breaks is currently a task that roughly 0.1% of PHP 
developers have the technical ability to even do.  Bring that up to 
5-10% and we may see a *much* better feedback loop.[4]


[1] Really, I can count on one hand the number of Drupal developers who 
even know C, much less can compile a complex C application.  I'm sure 
you could make all sorts of disparaging comments about Drupal/Drupalers 
as a result, and you'd be about 1/3 right, but nonetheless that's the 
situation.


[2] Drupal people are about 2/3 Macophiles, 1/3 Linux-istas, and 
occasionally we let a Windows user in so that we don't look 
discriminatory.  I don't know how that breaks down in other major 
sub-communities.


[3] We have a CI system in place but it's home grown, doesn't have 
enough human resources maintaining it, and I don't think it supports 
multiple variants of the PHP environment well.  Yes, this is a problem. 
 We're aware of that, but I don't expect it to change soon, unfortunately.


[4] As I am not part of that 0.1% I don't have much if any ability to 
help improve that number, or I would offer to do so.  My C-fu is about 8 
years old and was limited to Palm OS.


--Larry Garfield

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

Re: [PHP-DEV] Voting periods

2013-01-29 Thread Ralf Lang

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am 29.01.2013 17:55, schrieb Larry Garfield:
 On 1/29/13 5:08 AM, Pierre Joye wrote:
 hi Jan,
 
 On Tue, Jan 29, 2013 at 11:55 AM, Jan Ehrhardt
 php...@ehrhardt.nl wrote:
 Hi Pierre,
 
 Pierre Joye in php.internals (Tue, 29 Jan 2013 05:55:27
 +0100):
 This is one of the reason why the 'new' release process RFC
 does not allow BC breaks. But we can't be 100% sure that we
 do not introduce one without you, all projects and users,
 doing intensive testing using your apps, modules, plugins,
 etc. And before the final releases, not after.
 
 Question: Did you test D7/8 and their respective plugins with
 php 5.5?
 
 No. Reality: many Drupal users are beginning to move from
 Drupal 6 to Drupal 7 at the moment. So are we. The code freeze
 for Drupal 8 will be no sooner than July this year. And we have
 enough issues with D7 under PHP 5.4 to worry about BC breaks
 beyond PHP 5.4.
 
 What do you need to get D7 tested under 5.5? I mean once you have
 a CI in place, it is not hard to setup one instance to test 5.5.
 
 Waiting the final release of 5.5 won't be of any help, not for
 Drupal, not for us.
 
 Clear, detailed instructions aimed at someone who has *never used a
 C compiler before*[1] for how to build, install, and run a 5.5
 alpha, for Mac and for common Linuxes[2], that do not require doing
 screwy things with running multiple web servers on a single OS.  In
 fact, the ideal would be periodically released VirtualBox images
 with the latest alpha or beta tagged that we can just boot up and
 run.[3]
 
 The first point is, I think, the biggest blocker.  Try out the
 latest PHP and see what breaks is currently a task that roughly
 0.1% of PHP developers have the technical ability to even do.
 Bring that up to 5-10% and we may see a *much* better feedback
 loop.[4]
 

If that is the issue, I could probably set up an obs project for that,
which would autobuild a distribution package out of the git code at
select points in time. It could even go as far as autobuilding a
kvm/xen/virtualbox image. I do that kind of stuff for userland code
(Horde) but I never fealt it was something others could use.



- -- 
Ralf Lang
Linux Consultant / Developer
Tel.: +49-170-6381563
Mail: l...@b1-systems.de
B1 Systems GmbH
Osterfeldstra￟e 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlEIAPEACgkQCs1dsHJ/X7AGPACeLgsDMsHmZszlYF9jyR483CVh
mxAAmwUgix4jbTHEzVMMNECiJqtDso6f
=eX3a
-END PGP SIGNATURE-

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

Re: [PHP-DEV] Voting periods

hi Larry,

On Tue, Jan 29, 2013 at 5:55 PM, Larry Garfield la...@garfieldtech.com wrote:
On 1/29/13 5:08 AM, Pierre Joye wrote:

hi Jan,

On Tue, Jan 29, 2013 at 11:55 AM, Jan Ehrhardt php...@ehrhardt.nl wrote:

Hi Pierre,

Pierre Joye in php.internals (Tue, 29 Jan 2013 05:55:27 +0100):

This is one of the reason why the 'new' release process RFC does not
allow BC breaks. But we can't be 100% sure that we do not introduce
one without you, all projects and users, doing intensive testing using
your apps, modules, plugins, etc. And before the final releases, not
after.

Question: Did you test D7/8 and their respective plugins with php 5.5?

No. Reality: many Drupal users are beginning to move from Drupal 6 to
Drupal 7 at the moment. So are we. The code freeze for Drupal 8 will be
no sooner than July this year. And we have enough issues with D7 under
PHP 5.4 to worry about BC breaks beyond PHP 5.4.

What do you need to get D7 tested under 5.5? I mean once you have a CI
in place, it is not hard to setup one instance to test 5.5.

Waiting the final release of 5.5 won't be of any help, not for Drupal,
not for us.

Clear, detailed instructions aimed at someone who has *never used a C
compiler before*[1] for how to build, install, and run a 5.5 alpha, for Mac
and for common Linuxes[2], that do not require doing screwy things with
running multiple web servers on a single OS. In fact, the ideal would be
periodically released VirtualBox images with the latest alpha or beta tagged
that we can just boot up and run.[3]

The first point is, I think, the biggest blocker. Try out the latest PHP
and see what breaks is currently a task that roughly 0.1% of PHP developers
have the technical ability to even do. Bring that up to 5-10% and we may
see a *much* better feedback loop.[4]

[1] Really, I can count on one hand the number of Drupal developers who even
know C, much less can compile a complex C application. I'm sure you could
make all sorts of disparaging comments about Drupal/Drupalers as a result,
and you'd be about 1/3 right, but nonetheless that's the situation.

[2] Drupal people are about 2/3 Macophiles, 1/3 Linux-istas, and
occasionally we let a Windows user in so that we don't look discriminatory.
I don't know how that breaks down in other major sub-communities.

[3] We have a CI system in place but it's home grown, doesn't have enough
human resources maintaining it, and I don't think it supports multiple
variants of the PHP environment well. Yes, this is a problem. We're aware
of that, but I don't expect it to change soon, unfortunately.

[4] As I am not part of that 0.1% I don't have much if any ability to help
improve that number, or I would offer to do so. My C-fu is about 8 years
old and was limited to Palm OS.

Zero skills are required to setup a PHP. But a bit more clue is
required to test Drupal. I can help the PHP setup automation but would
need your help to setup D7+ setup with major plugins to automate the
tests. By the way, we already do it with Drupal 7 using the default
install in our labs (OSTC at Microsoft), regression, performance and
functional, with and without APC, on IIS and Apache, nts and zts. We
will add the o+ to the stack asap as well. See the following links for
example results:

http://windows.php.net/downloads/snaps/ostc/pftt/perf/results-20130125-5.5.0alpha4-5.5rd86e14b.html

Cheers,
--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

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

Re: [PHP-DEV] Voting periods

2013-01-29 Thread Attila Bukor

I think Ralf's idea is great. A lot of other projects use nightly builds
successfully. I don't think a vbox image would be necessary as no-one
would use nightly builds on a production environment, but if web developers
who feel a little adventurous could add an official PHP nightly-build
repository
to their Ubuntu's sources.list (I guess other distro's users can compile it
on
their own), it would be awesome.

r1pp3rj4ck


On Tue, Jan 29, 2013 at 6:03 PM, Ralf Lang l...@b1-systems.de wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Am 29.01.2013 17:55, schrieb Larry Garfield:
  On 1/29/13 5:08 AM, Pierre Joye wrote:
  hi Jan,
 
  On Tue, Jan 29, 2013 at 11:55 AM, Jan Ehrhardt
  php...@ehrhardt.nl wrote:
  Hi Pierre,
 
  Pierre Joye in php.internals (Tue, 29 Jan 2013 05:55:27
  +0100):
  This is one of the reason why the 'new' release process RFC
  does not allow BC breaks. But we can't be 100% sure that we
  do not introduce one without you, all projects and users,
  doing intensive testing using your apps, modules, plugins,
  etc. And before the final releases, not after.
 
  Question: Did you test D7/8 and their respective plugins with
  php 5.5?
 
  No. Reality: many Drupal users are beginning to move from
  Drupal 6 to Drupal 7 at the moment. So are we. The code freeze
  for Drupal 8 will be no sooner than July this year. And we have
  enough issues with D7 under PHP 5.4 to worry about BC breaks
  beyond PHP 5.4.
 
  What do you need to get D7 tested under 5.5? I mean once you have
  a CI in place, it is not hard to setup one instance to test 5.5.
 
  Waiting the final release of 5.5 won't be of any help, not for
  Drupal, not for us.
 
  Clear, detailed instructions aimed at someone who has *never used a
  C compiler before*[1] for how to build, install, and run a 5.5
  alpha, for Mac and for common Linuxes[2], that do not require doing
  screwy things with running multiple web servers on a single OS.  In
  fact, the ideal would be periodically released VirtualBox images
  with the latest alpha or beta tagged that we can just boot up and
  run.[3]
 
  The first point is, I think, the biggest blocker.  Try out the
  latest PHP and see what breaks is currently a task that roughly
  0.1% of PHP developers have the technical ability to even do.
  Bring that up to 5-10% and we may see a *much* better feedback
  loop.[4]
 

 If that is the issue, I could probably set up an obs project for that,
 which would autobuild a distribution package out of the git code at
 select points in time. It could even go as far as autobuilding a
 kvm/xen/virtualbox image. I do that kind of stuff for userland code
 (Horde) but I never fealt it was something others could use.



 - --
 Ralf Lang
 Linux Consultant / Developer
 Tel.: +49-170-6381563
 Mail: l...@b1-systems.de
 B1 Systems GmbH
 Osterfeldstra￟e 7 / 85088 Vohburg / http://www.b1-systems.de
 GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2.0.19 (GNU/Linux)
 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

 iEYEARECAAYFAlEIAPEACgkQCs1dsHJ/X7AGPACeLgsDMsHmZszlYF9jyR483CVh
 mxAAmwUgix4jbTHEzVMMNECiJqtDso6f
 =eX3a
 -END PGP SIGNATURE-

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

Re: [PHP-DEV] Voting periods

On Tue, Jan 29, 2013 at 6:24 PM, Attila Bukor attila.bu...@gmail.com wrote:
 I think Ralf's idea is great. A lot of other projects use nightly builds
 successfully. I don't think a vbox image would be necessary as no-one
 would use nightly builds on a production environment,

It is not about using anything in prod but catch bugs as early as
possible in the QA process.


--
Pierre

@pierrejoye

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

Re: [PHP-DEV] Voting periods

2013-01-29 Thread Ralf Lang

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am 29.01.2013 18:38, schrieb Pierre Joye:
 On Tue, Jan 29, 2013 at 6:24 PM, Attila Bukor
 attila.bu...@gmail.com wrote:
 I think Ralf's idea is great. A lot of other projects use nightly
 builds successfully. I don't think a vbox image would be
 necessary as no-one would use nightly builds on a production
 environment,
 
 It is not about using anything in prod but catch bugs as early as 
 possible in the QA process.

I understand that. Automated distribution packaging of wip code is not
meant for production but for rapid deployment of clean state test
environments. It's similar to a CI suite.

If there is enough interest in php snapshots as rpm, I could begin
such a setup on monday.


- -- 
Ralf Lang
Linux Consultant / Developer
Tel.: +49-170-6381563
Mail: l...@b1-systems.de
B1 Systems GmbH
Osterfeldstra￟e 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlEICvoACgkQCs1dsHJ/X7A+qwCfTaEjuuHa8ztw4cUaIXYzR9v0
hscAoPX9oBdipdFA0XXB7Rds8JIfmei+
=9ccU
-END PGP SIGNATURE-

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

Re: [PHP-DEV] Voting periods

2013-01-29 Thread Attila Bukor

On Tue, Jan 29, 2013 at 6:46 PM, Ralf Lang l...@b1-systems.de wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Am 29.01.2013 18:38, schrieb Pierre Joye:
  On Tue, Jan 29, 2013 at 6:24 PM, Attila Bukor
  attila.bu...@gmail.com wrote:
  I think Ralf's idea is great. A lot of other projects use nightly
  builds successfully. I don't think a vbox image would be
  necessary as no-one would use nightly builds on a production
  environment,
 
  It is not about using anything in prod but catch bugs as early as
  possible in the QA process.

I know. I don't know why I said that part, but it's still unnecessary to
build vbox
images imho. Users can install deb packages. We should focus on providing a
Debian repository for nightly builds instead.


 I understand that. Automated distribution packaging of wip code is not
 meant for production but for rapid deployment of clean state test
 environments. It's similar to a CI suite.

I think it was meant for me :)


 If there is enough interest in php snapshots as rpm, I could begin
 such a setup on monday.

I could do that for Archlinux, but I'm not sure there are any Arch users
who can't
build it for themselves.





 - --
 Ralf Lang
 Linux Consultant / Developer
 Tel.: +49-170-6381563
 Mail: l...@b1-systems.de
 B1 Systems GmbH
 Osterfeldstra￟e 7 / 85088 Vohburg / http://www.b1-systems.de
 GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2.0.19 (GNU/Linux)
 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

 iEYEARECAAYFAlEICvoACgkQCs1dsHJ/X7A+qwCfTaEjuuHa8ztw4cUaIXYzR9v0
 hscAoPX9oBdipdFA0XXB7Rds8JIfmei+
 =9ccU
 -END PGP SIGNATURE-

Re: [PHP-DEV] Voting periods

2013-01-29 Thread Larry Garfield


On 1/29/13 11:46 AM, Ralf Lang wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am 29.01.2013 18:38, schrieb Pierre Joye:

On Tue, Jan 29, 2013 at 6:24 PM, Attila Bukor
attila.bu...@gmail.com wrote:

I think Ralf's idea is great. A lot of other projects use nightly
builds successfully. I don't think a vbox image would be
necessary as no-one would use nightly builds on a production
environment,


It is not about using anything in prod but catch bugs as early as
possible in the QA process.


I understand that. Automated distribution packaging of wip code is not
meant for production but for rapid deployment of clean state test
environments. It's similar to a CI suite.

If there is enough interest in php snapshots as rpm, I could begin
such a setup on monday.


If I could run my own VM (that much I can do) and periodically just do 
apt-get update php-head, that would lower the barrier to testing new 
versions by several orders of magnitude.  (Yeah yeah insert RPM vs. Apt 
debate here; both are good to have.)  That would be *sweet*. +1


--Larry Garfield

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

Re: [PHP-DEV] Voting periods

2013-01-29 Thread Rasmus Lerdorf

On 01/29/2013 12:43 PM, Larry Garfield wrote:
 On 1/29/13 11:46 AM, Ralf Lang wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Am 29.01.2013 18:38, schrieb Pierre Joye:
 On Tue, Jan 29, 2013 at 6:24 PM, Attila Bukor
 attila.bu...@gmail.com wrote:
 I think Ralf's idea is great. A lot of other projects use nightly
 builds successfully. I don't think a vbox image would be
 necessary as no-one would use nightly builds on a production
 environment,

 It is not about using anything in prod but catch bugs as early as
 possible in the QA process.

 I understand that. Automated distribution packaging of wip code is not
 meant for production but for rapid deployment of clean state test
 environments. It's similar to a CI suite.

 If there is enough interest in php snapshots as rpm, I could begin
 such a setup on monday.
 
 If I could run my own VM (that much I can do) and periodically just do
 apt-get update php-head, that would lower the barrier to testing new
 versions by several orders of magnitude.  (Yeah yeah insert RPM vs. Apt
 debate here; both are good to have.)  That would be *sweet*. +1

Is building from git really that much harder? Yes, it takes a little bit
of tweaking to get your configure flags right and getting all the right
dev versions of the dependencies installed, but at least on
Debian/Ubuntu (since you mentioned apt) you have the quick shortcut of
doing:

  apt-get build-dep php5

which installs everything you should need to build it.

I usually keep a little cn script around which is just a saved
config.nice that I hack on when I am testing stuff. You can see a
slightly simplified version of the one I use for 5.5 here:

  http://lerdorf.com/cn.txt

If you don't have a checkout of the tree already, do:

  git clone -b PHP-5.5 git://git.php.net/php-src.git

Not that this actually checks out all the branches, but puts you on the
5.5 branch automatically. You can switch branches without redownloading
to test other versions.

  cd php-src
  ./buildconf
  ./cn
  make
  make install

All done. To check updated versions, just cd into your php-src directory
and type:

  git pull
  ./buildconf
  ./cn
  make
  make install

You may sometimes need to do a make clean and for minor changes you
can skip the builconf and configure and just make again and hope the
make dependency system works.

I realize this is slightly more complicated than an apt-get, but
pre-building packages that will work with all the combinations of
libraries and things out there is a PITA. By building your own you get
to choose everything by editing your cn script.

-Rasmus

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

Re: [PHP-DEV] Voting periods

2013-01-29 Thread Rasmus Lerdorf

On 01/29/2013 01:12 PM, Rasmus Lerdorf wrote:
 I realize this is slightly more complicated than an apt-get, but
 pre-building packages that will work with all the combinations of
 libraries and things out there is a PITA. By building your own you get
 to choose everything by editing your cn script.

And since this is a dev tree, it sometimes doesn't build. Like if you
try these steps right now it will die trying to build ext/curl. It
should be fixed shortly as soon as Stas commits the missing curl_file.c

-Rasmus

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

Re: [PHP-DEV] Voting periods

2013-01-29 Thread Jan Ehrhardt

Pierre Joye in php.internals (Tue, 29 Jan 2013 05:55:27 +0100):
Question: Did you test D7/8 and their respective plugins with php 5.5?

OK. A part of that challenge I took: compile PHP 5.5 Alpha 4 ZTS for
Windows with as many extensions as I could. The result:

http://dl.dropbox.com/u/8954372/php-5.5.0alpha4-Win32-VC9-x86.zip

Extensions that did not compile:
php_apc.dll
php_pthreads.dll
php_xcache.dll
php_xdebug.dll
php_suhosin.dll
php_sqlsrv.dll

But more than 60 others did.

To my surprise the snapshot build compiled php_wincache.dll.
php_wincache.dll is meant for NTS, so I removed it from the zip-file.
However, there is a chance php_wincache.dll will work with PHP 5.5 NTS.

Tonight I will compile PHP 5.5 as NTS. The compiling was awfully slow,
so you will have to wait for a while.

Note: I only tested if the modules compiled. I did not test them yet.
But if anyone wants to test all those extensions: feel free to do it.

Jan

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

[PHP-DEV] packaged and manual builds Re: [PHP-DEV] Voting periods

2013-01-29 Thread Ralf Lang

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

 Is building from git really that much harder? Yes, it takes a
 little bit of tweaking to get your configure flags right and
 getting all the right dev versions of the dependencies installed,
 but at least on Debian/Ubuntu (since you mentioned apt) you have
 the quick shortcut of doing:
 
 apt-get build-dep php5
 
 which installs everything you should need to build it.
 
 I usually keep a little cn script around which is just a saved 
 config.nice that I hack on when I am testing stuff. You can see a 
 slightly simplified version of the one I use for 5.5 here:
 
 http://lerdorf.com/cn.txt
 
 If you don't have a checkout of the tree already, do:
 
 git clone -b PHP-5.5 git://git.php.net/php-src.git
 
 Not that this actually checks out all the branches, but puts you on
 the 5.5 branch automatically. You can switch branches without
 redownloading to test other versions.
 
 cd php-src ./buildconf ./cn make make install
 
 All done. To check updated versions, just cd into your php-src
 directory and type:
 
 git pull ./buildconf ./cn make make install
 
 You may sometimes need to do a make clean and for minor changes
 you can skip the builconf and configure and just make again and
 hope the make dependency system works.

Nothing's wrong with that. With building in obs you just get a clean
room build. You cannot forget to make clean, you won't get side
effects of some optional library installed by some 3rd application or
not, it's reproducible and shareable. It doesn't add anything if you
don't need this.

 
 I realize this is slightly more complicated than an apt-get, but 
 pre-building packages that will work with all the combinations of 
 libraries and things out there is a PITA.

Yes, building for arbitrary combinations by hand is not what everybody
wants. When you build locally, you don't care and don't want to care
about different setups which have to work with your procedure. You
choose what suits you best.

Packaging a git build with a well-known (inherited from last
distribution) php build configuration may help early detection of
issues that come up with exactly that set of tools and libraries. It's
not fundamentally different from the manual procedure.

The one thing apt-get/zypper saves is time. You eliminate the commit
states which won't build at all, at least for the end users. Now they
have more time to figure how they make their legacy code work with the
newest git PHP and why their test suite fails out of sudden - be it
new features/BC break or a real bug.

- -- 
Ralf Lang
Linux Consultant / Developer
Tel.: +49-170-6381563
Mail: l...@b1-systems.de
B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlEIUfoACgkQCs1dsHJ/X7CGBQCfa/Xd9FmQdKZArVfHXDLd4Sbn
WfIAn1pqyd8QAQRTnzKJnWPTGDUDF4Tg
=qV0h
-END PGP SIGNATURE-

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

RE: [PHP-DEV] Voting periods

2013-01-29 Thread Attila Bukor

This is why I think the best way to deal with the situation is
distributing nightly builds. First of all, we could use the
distributions' make-package files to build the package. And what if it
returns with an error code? Big deal, either no new nightly build on
that day (and report a failure to a dedicated mailing list or
somewhere), or it could try again with HEAD^ and HEAD^^ and so on until
it reaches the latest successful nightly build or it finally builds it
with no errors. Btw, I think it always should use make clean before
compiling.

r1pp3rj4ck
From: Rasmus Lerdorf
Sent: 29/01/2013 22:31
To: Larry Garfield
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Voting periods
On 01/29/2013 01:12 PM, Rasmus Lerdorf wrote:
 I realize this is slightly more complicated than an apt-get, but
 pre-building packages that will work with all the combinations of
 libraries and things out there is a PITA. By building your own you get
 to choose everything by editing your cn script.

And since this is a dev tree, it sometimes doesn't build. Like if you
try these steps right now it will die trying to build ext/curl. It
should be fixed shortly as soon as Stas commits the missing curl_file.c

-Rasmus

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

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

Re: [PHP-DEV] packaged and manual builds Re: [PHP-DEV] Voting periods

2013-01-29 Thread Rasmus Lerdorf

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/29/2013 02:49 PM, Ralf Lang wrote:
 The one thing apt-get/zypper saves is time. You eliminate the
 commit states which won't build at all, at least for the end users.
 Now they have more time to figure how they make their legacy code
 work with the newest git PHP and why their test suite fails out of
 sudden - be it new features/BC break or a real bug.

It is actually pretty rare that we break the build. Just an
unfortunate coincidence that it is broken right now when I posted this.

- -Rasmus
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlEIU3QACgkQlxayKTuqOuCb6QCdElhSnbAPoMq33qZyHj75GSL3
w/QAn125NEDi2WZDEXuekcq5Qq9fau7T
=2M2u
-END PGP SIGNATURE-

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

Re: [PHP-DEV] packaged and manual builds Re: [PHP-DEV] Voting periods