Hi,
There’s something that I’m not quite following regarding open votes.
Why are we saying that ‘votes will end no sooner than X’, instead of
actually saying when they will end?
If there’s no clear end date for a vote, when do we declare than a vote is
over? Is it in a specific point in time where the vote happens to be in
favor with what the proposer wanted?
The specific case in point is
https://wiki.php.net/rfc/propertygetsetsyntax-v1.2 - which while has more
supporters than opposers, consistent fell short of the 2/3 majority it
needs to be approved. The vote should have ended on Wednesday – 4 days
ago, but for some reason it’s still open. It’s time to close it.
My suggestion is for voting periods to be limited to one week, regardless
of the topic. It should be more than enough. Regardless, an ‘open ended’
voting period is unacceptable IMHO.
Zeev
hi,
Hi,
There’s something that I’m not quite following regarding open votes.
Why are we saying that ‘votes will end no sooner than X’, instead of
actually saying when they will end?If there’s no clear end date for a vote, when do we declare than a vote is
over? Is it in a specific point in time where the vote happens to be in
favor with what the proposer wanted?
Itt was more defined as a "minimum voting period".
The specific case in point is
https://wiki.php.net/rfc/propertygetsetsyntax-v1.2 - which while has more
supporters than opposers, consistent fell short of the 2/3 majority it
needs to be approved. The vote should have ended on Wednesday – 4 days
ago, but for some reason it’s still open. It’s time to close it.My suggestion is for voting periods to be limited to one week, regardless
of the topic. It should be more than enough. Regardless, an ‘open ended’
voting period is unacceptable IMHO.
You were one of the person who requested to have at least two weeks,
so nobody can miss a vote due to various reasons (on the road, off
time, or whatever else). I'd to keep two weeks.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
My suggestion is for voting periods to be limited to one week,
regardless of the topic. It should be more than enough. Regardless,
an 'open
ended'
voting period is unacceptable IMHO.You were one of the person who requested to have at least two weeks, so
nobody can miss a vote due to various reasons (on the road, off time, or
whatever else). I'd to keep two weeks.
Well the way it is right now it's a 'one week by default', unless there
are reasons to extend it, which IIRC was the compromise. I find it
difficult to believe that had this particular RFC been in an 'accepted'
position back on Wednesday the 23rd, the vote wouldn't have immediately
closed...
In my opinion - based on our actual experience now as opposed to
theoretical predictions which we had back then - one week should be enough
as the default. But I'm fine going with two weeks. I guess we'll vote on
that too :) It's more important to have a definite end date than whether
it's one week or two weeks.
Zeev
hi,
My suggestion is for voting periods to be limited to one week,
regardless of the topic. It should be more than enough. Regardless,
an 'open
ended'
voting period is unacceptable IMHO.You were one of the person who requested to have at least two weeks, so
nobody can miss a vote due to various reasons (on the road, off time, or
whatever else). I'd to keep two weeks.Well the way it is right now it's a 'one week by default', unless there
are reasons to extend it, which IIRC was the compromise. I find it
difficult to believe that had this particular RFC been in an 'accepted'
position back on Wednesday the 23rd, the vote wouldn't have immediately
closed...
I find somehow disturbing that you raised that for the RFC you don't
like, that has to be said :) You also, if I am not mistaken, changed
your vote during the week. That's all good, but changing rules to get
the results we wish is not going to happen.
In my opinion - based on our actual experience now as opposed to
theoretical predictions which we had back then - one week should be enough
as the default. But I'm fine going with two weeks. I guess we'll vote on
that too :) It's more important to have a definite end date than whether
it's one week or two weeks.
One week is too short, I'd to go with two weeks minumum, end date must
be set when a vote begins, to avoid any confusions.
I will add a vote on that in the voting RFC, as un update, so we will
a clear(er) position for the next RFCs.
Cheers,
Pierre
@pierrejoye
-----Original Message-----
From: Pierre Joye [mailto:pierre.php@gmail.com]
Sent: Monday, January 28, 2013 1:07 PM
To: Zeev Suraski
Cc: PHP internals
Subject: Re: [PHP-DEV] Voting periodshi,
My suggestion is for voting periods to be limited to one week,
regardless of the topic. It should be more than enough.
Regardless,
an 'open
ended'
voting period is unacceptable IMHO.You were one of the person who requested to have at least two weeks,
so nobody can miss a vote due to various reasons (on the road, off
time, or whatever else). I'd to keep two weeks.Well the way it is right now it's a 'one week by default', unless
there are reasons to extend it, which IIRC was the compromise. I find
it difficult to believe that had this particular RFC been in an
'accepted'
position back on Wednesday the 23rd, the vote wouldn't have
immediately closed...I find somehow disturbing that you raised that for the RFC you don't
like, that
has to be said :)
That's fair, but it's the only one of 6 open RFCs right now that has an
intentional open-ended ending date.
You also, if I am not mistaken, changed your vote during the
week.
I was never in favor of this feature, in all of its different
incarnations. I did not change my vote.
That's all good, but changing rules to get the results we wish is not
going
to happen.
I feel that this is what was done in this particular case, not the other
way around. That what brought me to bring up that subject here in the
first place. This particular RFC was the only RFC where I noticed this
weird 'no sooner than' language, and it seemed intentional to me - given
the fact it's a very controversial feature opposed by most core devs.
If we want to change the default voting period to two weeks, that's fine -
but IMHO it should be for future RFCs after it gets approved.
In my opinion - based on our actual experience now as opposed to
theoretical predictions which we had back then - one week should be
enough as the default. But I'm fine going with two weeks. I guess
we'll vote on that too :) It's more important to have a definite end
date than whether it's one week or two weeks.One week is too short, I'd to go with two weeks minumum, end date must
be set
when a vote begins, to avoid any confusions.I will add a vote on that in the voting RFC, as un update, so we will a
clear(er)
position for the next RFCs.
OK, please put a one week as an option too. To put things in perspective,
elections that effect the fate of billions of people typically end in
24hrs.
Zeev
I will add a vote on that in the voting RFC, as un update, so we will a
clear(er)
position for the next RFCs.OK, please put a one week as an option too. To put things in perspective,
elections that effect the fate of billions of people typically end in
24hrs.
Yes, I was thinking about having 1, 2 or 3 weeks as options, or just 1
or 2, 3 looks long to me :)
--
Pierre
@pierrejoye
I feel that this is what was done in this particular case, not the
other way around. That what brought me to bring up that subject here
in the first place. This particular RFC was the only RFC where I
noticed this weird 'no sooner than' language, and it seemed
intentional to me - given the fact it's a very controversial feature
opposed by most core devs. If we want to change the default voting
period to two weeks, that's fine - but IMHO it should be for future
RFCs after it gets approved.
Actually, it was not done on purpose but was mimicking what many other
RFC "vote sections" do, I thought it was the way it was supposed to be
done, see:
https://wiki.php.net/rfc/incompat_ctx
https://wiki.php.net/rfc/array_column
If you're still worried about this making it in, don't worry. Nikita and
I have given up, to the determinant of the community.
-Clint
Zeev
--
-Clint
If you're still worried about this making it in, don't worry. Nikita and I
have given up, to the determinant of the community.
Then please close the voting.
If you're still worried about this making it in, don't worry. Nikita and I
have given up, to the determinant of the community.Then please close the voting.
Since there is no "maximum voting period" and 5.5 is not in a feature
freeze yet, I left the voting open, in case some people decided to read
the patch and change their minds. I see no reason to close the vote
unless I'm required to do so or the game is up.
I share Pierre's sentiment that this vote is pretty ridiculous. People
have been asking for this feature (present in every other modern
language) for 5+ years. I spent two years going through the tedious
RFC discussion process, wrote the software, Nikita made it even better
to have it shot down without even reasonable explanations as to why
"from most people."
Some people gave good explanations (Sherif Ramadan) even if I don't
agree with them. Very few others did and it really leaves us/me with no
direction to go. No reason for the rejection ergo no way to "improve
this, or improve that."
Some are resting on the idea that the ROI isn't there just aren't
listening to the community.
I'd love nothing more than to have this proposal accepted, and perhaps I
will give it another go in the future. I figured at the very least I
should contribute in other ways to PHP so that I eliminate the "big RFC
from a new developer" aspect of the situation, which I think ultimately
was the deciding factor.
-Clint
--
-Clint
I also disagree with an open-ended voting period. I'm fine with having
a long voting window, but when a vote is called it should declare when
the voting will end. This just makes sense to me.
Since we're on the topic of voting, I also want to bring up that 50% +
1 is actually pretty low for something that doesn't modify the core.
For instance, suppose that the voting on an RFC ended with exactly a
50% + 1 vote in favor of adding the feature. That means that half of
the people who voted did not want it to go through. That seems like a
problem to me; half of the people were against it yet it is accepted
and introduced to the language? Maybe I'm used to working in councils
that require near unanimity, but 50% + 1 seems very, very low. If
we're going to revisit voting, can we re-discuss this as well?
-----Original Message-----
From: Clint Priest [mailto:cpriest@zerocue.com]
Sent: Monday, January 28, 2013 3:15 PM
To: Peter Cowburn
Cc: Zeev Suraski; Pierre Joye; PHP internals
Subject: Re: [PHP-DEV] Voting periodsIf you're still worried about this making it in, don't worry. Nikita
and I have given up, to the determinant of the community.Then please close the voting.
Since there is no "maximum voting period" and 5.5 is not in a feature
freeze yet,
I left the voting open, in case some people decided to read the patch
and change
their minds. I see no reason to close the vote unless I'm required to
do so or the
game is up.
I think there's an almost-consensus that voting periods need to be well
defined. Two reasons:
- If you care enough about it you should be able to vote about it within
one or two weeks. - Leaving it open ended gives the RFC proposer too much power. He could
simply end the vote once it happens to reach the necessary majority.
So I'd say yes, you're required to end it, either immediately or at most
at the end of the two week boundary.
asking for this feature (present in every other modern
language) for 5+ years. I spent two years going through the tedious
RFC
discussion process, wrote the software, Nikita made it even better to
have it
shot down without even reasonable explanations as to why "from most
people."
There are two very reasonable explanations, and it's fine you may disagree
with them:
- It makes the language more complex.
- It makes the language more difficult to maintain.
In both cases, the people who opposed it thought that the gain from adding
it doesn't outweigh these loss in complexity and maintenance overhead.
Some are resting on the idea that the ROI isn't there just aren't
listening to the
community.
The vast majority of the PHP community is a silent one; These people
don't participate here on internals; They don't attend conferences; They
use it - the vast majority of them in a professional manner - and they
picked it because they like it the way it is, not because of what it needs
to become. For every person that subscribes to internals, there's a
thousand (yes, a THOUSAND) people who don't (it's several thousands vs.~5
million). In fact, they're not completely silent. They speak in volumes
- PHP 5.4 is used in less than 1% of the sites using PHP today, and even
the relatively revolutionary 5.3 is still a lot less popular than 5.2.
The new shiny features are not all that interesting for most people.
The community that participates in internals isn't necessarily
representative of the community at large.
Zeev
On Jan 28, 2013 6:07 PM, "Zeev Suraski"
The community that participates in internals isn't necessarily
representative of the community at large.
Letzten me clarify my view. I do not attend hyped conferences, because I
want to meet are not there. However I meet a lot of our "silent" community,
inside companies, customers, non PHP specific conferences, UGs, schools
(for active ppl), etc. My opinion and my certitude about this feature are
based on the feedback of these people.
However, projects leaders have the same feedbacks from their users, that
says all.
I think many of us are purely and simply totally out of sync with our
users. I have no immediate solution but this is something we must solve,
now.
I agree, but we’re in opposite camps on this feature. What does that mean?
J
I think many of us are purely and simply totally out of sync with our
users. I have no immediate solution but this is something we must solve,
now.
I agree, but we’re in opposite camps on this feature. What does that
mean? J
Go back to our roots? :-)
Zeev Suraski wrote:
They speak in volumes
- PHP 5.4 is used in less than 1% of the sites using PHP today, and even
the relatively revolutionary 5.3 is still a lot less popular than 5.2.
The new shiny features are not all that interesting for most people.
And I wonder how many of the 1% using 5.4 live are using it purely because they
HAVE spent the time to get 5.2 based code working clean on it rather than
because they use any of the 'new shiny features' ... I'm about 50% through the
move to 5.4 and it will be some time before the rest can be moved of the PHP5.2
machines. It does now seem a 'false economy' simply to hide the problems with
the code rather than making the code run clean so sticking with a suitable
machine is safer than trying to selectively get a 5.4 machine run both 5.2
'dirty' code as well as 5.4 'clean' code?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
The vast majority of the PHP community is a silent one; These people
...
In fact, they're not completely silent. They speak in volumes
- PHP 5.4 is used in less than 1% of the sites using PHP today, and even
the relatively revolutionary 5.3 is still a lot less popular than 5.2.
The new shiny features are not all that interesting for most people.
Can we stop calling things "new shiny features" as if that means
anything? It's empty rhetoric. When you treat your users like
unintelligent noobies who are just going to hang themselves when you
give them a rope, then that's the type of users you will end up with.
As a long time (silent) PHP user of 10+ years, these are exactly the
types of features that I and everybody I work with as professionals
who write our own code would like to see in PHP. The second PHP 5.5 is
out, I'll be updating just to have easy-to-use iterators (i.e.,
generators).
As somebody who has been actively involved on another large open
source project for 15 years, I can appreciate the desire to avoid
adding pointless complexity. In fact, I think putting properties into
something already in alpha state (5.5) is not wise. But the feature
itself is spot-on, and to claim that using __get and __set is better
or sufficient is a hard position to back up.
Pointing to usage of PHP 5.4 as any sort of justification is
meaningless. What's happening is that the average PHP user is simply
turning into a person who uses few old, mainstream PHP applications
like Wordpress because PHP lacks the features to be competitive with
other languages. So it's things like Wordpress that are driving the
big numbers, which has nothing to do with the number of individual
people who write their own serious, modern software.
And for the discussion at hand, yes, it seems obvious that every RFC
should have an absolute deadline of when voting ends.
--
Matthew Leverton
In the past months, I talked to a lot of German companies using PHP or Java:
All PHP companies were using 5.2/5.3 and planned to upgrade to 5.4.
Almost all were using default binaries from their favorite Linux
distribution on their production systems.
Only one was building their own extensions, based on the book from 2006.
None of them complained about missing features or security problems.
None of them complained about quality of PHP or missing documentation
in userland functions.
Those who chose Java did it because of better IDE support, tools for
static code analysis (FindBugs) and the compiler giving warnings (e.g.
code calls non-existing methods).
None of them mentioned they are using or needing a debugger.
Those who chose PHP did it because they want things going quickly and
want cheap programmers without academic graduation.
Those who had performance problems, mainly had a shop framework
producing bad queries.
Most choose a PHP framework because it is the biggest and well-known.
Most did not run automatic tests. Those who did testing mainly did
selenium or unit tests for important functions.
Those who were using Wordpress confirmed they did not look into the
code before using it in production.
Regards,
Thomas
The vast majority of the PHP community is a silent one; These people
...
In fact, they're not completely silent. They speak in volumes
- PHP 5.4 is used in less than 1% of the sites using PHP today, and even
the relatively revolutionary 5.3 is still a lot less popular than 5.2.
The new shiny features are not all that interesting for most people.Can we stop calling things "new shiny features" as if that means
anything? It's empty rhetoric. When you treat your users like
unintelligent noobies who are just going to hang themselves when you
give them a rope, then that's the type of users you will end up with.
As a long time (silent) PHP user of 10+ years, these are exactly the
types of features that I and everybody I work with as professionals
who write our own code would like to see in PHP. The second PHP 5.5 is
out, I'll be updating just to have easy-to-use iterators (i.e.,
generators).As somebody who has been actively involved on another large open
source project for 15 years, I can appreciate the desire to avoid
adding pointless complexity. In fact, I think putting properties into
something already in alpha state (5.5) is not wise. But the feature
itself is spot-on, and to claim that using __get and __set is better
or sufficient is a hard position to back up.Pointing to usage of PHP 5.4 as any sort of justification is
meaningless. What's happening is that the average PHP user is simply
turning into a person who uses few old, mainstream PHP applications
like Wordpress because PHP lacks the features to be competitive with
other languages. So it's things like Wordpress that are driving the
big numbers, which has nothing to do with the number of individual
people who write their own serious, modern software.And for the discussion at hand, yes, it seems obvious that every RFC
should have an absolute deadline of when voting ends.--
Matthew Leverton
Can we stop calling things "new shiny features" as if that means
anything? It's
empty rhetoric. When you treat your users like unintelligent noobies who
are
just going to hang themselves when you give them a rope, then that's the
type
of users you will end up with.
If it doesn't mean anything, why does it bother you?
You don't need to be dumb to appreciate simplicity, and you can be very
intelligent and still appreciate complexity. The people behind J2EE were
all exceptionally smart.
PHP has become the most popular Web language in existence WITHOUT these
features. Most users couldn't care less about them. They're happy
without them. They're happier without them. They'd rather a faster PHP
that did exactly the same thing it does today - and not a slower one with
more features that's more difficult to learn and debug. The whole concept
of 'WE MUST ADD THIS TO PHP OR ELSE' is ludicrous in my opinion. PHP is
doing well, and many of the people who opposed this RFC are responsible
for steering it that way.
Zeev
Zeev Suraski wrote:
PHP has become the most popular Web language in existence WITHOUT these
features. Most users couldn't care less about them. They're happy
without them. They're happier without them. They'd rather a faster PHP
that did exactly the same thing it does today - and not a slower one with
more features that's more difficult to learn and debug. The whole concept
of 'WE MUST ADD THIS TO PHP OR ELSE' is ludicrous in my opinion. PHP is
doing well, and many of the people who opposed this RFC are responsible
for steering it that way.
Nicely put Zeev ...
I would add though ... most users have no idea how to rewrite the code they are
using to cope with the deprecated warnings? Somebody has to find time to do it
for them :(
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
2013/1/28 Zeev Suraski zeev@zend.com
-----Original Message-----
From: Clint Priest [mailto:cpriest@zerocue.com]
Sent: Monday, January 28, 2013 3:15 PM
To: Peter Cowburn
Cc: Zeev Suraski; Pierre Joye; PHP internals
Subject: Re: [PHP-DEV] Voting periodsIf you're still worried about this making it in, don't worry. Nikita
and I have given up, to the determinant of the community.Then please close the voting.
Since there is no "maximum voting period" and 5.5 is not in a feature
freeze yet,
I left the voting open, in case some people decided to read the patch
and change
their minds. I see no reason to close the vote unless I'm required to
do so or the
game is up.I think there's an almost-consensus that voting periods need to be well
defined. Two reasons:
- If you care enough about it you should be able to vote about it within
one or two weeks.- Leaving it open ended gives the RFC proposer too much power. He could
simply end the vote once it happens to reach the necessary majority.So I'd say yes, you're required to end it, either immediately or at most
at the end of the two week boundary.asking for this feature (present in every other modern
language) for 5+ years. I spent two years going through the tedious
RFC
discussion process, wrote the software, Nikita made it even better to
have it
shot down without even reasonable explanations as to why "from most
people."There are two very reasonable explanations, and it's fine you may disagree
with them:
- It makes the language more complex.
- It makes the language more difficult to maintain.
This is not accurate. There are people who would like to see a feature
implemented, but voted no because they did not like the proposed
implementation. This is important. A blunt "No" blocks not only the RFC
itself but also all attempts for alternative or improved solutions.
I believe that all proposals should have 3 options: "Yes, all the way",
"Yes in principle, but not this implementation" and "No in principle". This
would leave room for better approaches.
In both cases, the people who opposed it thought that the gain from adding
it doesn't outweigh these loss in complexity and maintenance overhead.Some are resting on the idea that the ROI isn't there just aren't
listening to the
community.The vast majority of the PHP community is a silent one; These people
don't participate here on internals; They don't attend conferences; They
use it - the vast majority of them in a professional manner - and they
picked it because they like it the way it is, not because of what it needs
to become. For every person that subscribes to internals, there's a
thousand (yes, a THOUSAND) people who don't (it's several thousands vs.~5
million). In fact, they're not completely silent. They speak in volumes
- PHP 5.4 is used in less than 1% of the sites using PHP today, and even
the relatively revolutionary 5.3 is still a lot less popular than 5.2.
The new shiny features are not all that interesting for most people.The community that participates in internals isn't necessarily
representative of the community at large.Zeev
--
Lazare INEPOLOGLOU
Ingénieur Logiciel
To Zeev and the rest of internals,
I know this will be a long e-mail but I'm not a guy who goes to conferences
(I don't have money for that), I've been into seven companies until now,
each with various use cases for PHP and I'm trying to contribute to some
open source projects from PHP scene.
You say that most of the users don't speak so I'll try to speak as my
previous attempts where ignored...
Let's start with the broken image about PHP 5.4 and adoption rate.
I'm not sure where, but today was given the argument of not doing userland
BC breaks while in 5.x branch, yet you just did that for 5.4 and now you use
it as a reference for adoption rate.
PHP 5.4 adoption rate is the best indicator but not for the number of
people
who like new features but rather for the number of people who can afford to
run without APC or have clean code.
Why do I say that? Consider this: since there's no common API for XCache/
Zend (forgot it's name) and other opcode accelerators/cachers I can't
upgrade
to use another alternative. And who's to say they don't suffer from their
own
bugs? Do you know what happens when I ask my NOC guys to install some
new extension? Things like: is it stable? Will it crash and burn my very
sensitive yet stable servers? Is it faster/slower that the alternatives?
Testing
the changes alone will make my company waste more money that having
me coming up with clever ways to provide workarounds or design things for
them so that upgrades like this can be avoided.
PHP 5.4 broke yet another thing. You've removed usage of register_globals.
That's a great thing but you've locked out many shared hosts as they can't
upgrade without making the customers upgrade their code first. That might
not even be possible for some people. I happen to maintain such a badly
written application, but it's working like that since 2002 and I can't
believe
that my employer will ask me to upgrade it at some point to make it
compatible with 5.4+. But I can do that, can you say the same thing for the
rest of the world?
I'd love to use traits in projects, there's great usage for them,
especially when
you go and write OOP code, the proper way... Can I do it? Sure, I have a
VPS which allows me to experiment but that's about it.
Thank God, you'll stop supporting 5.3 next year which is actually the reason
for why I'll be porting the application to 5.4, if possible, if not, 5.3
then 5.4
another time ;)
Why do I need those new features in the first place?
Just because I might be experimented enough in order to understand the
benefits from having them and how to use them to their true potential.
I don't understand feature X? Well ok, I need to read more about it. But
some smarter guys that make frameworks, ORMs, CMSs and other
large adopted and used PHP applications understand them, want them
need them to provide better code for people to use, learn from and write.
You think that majority of people write PHP in a professional way?
Could very well be true, in your countries, in mine, the focus is on getting
things done, nice if possible, if not, don't sacrifice the business time to
write nice code. I still manage to write nice code under these conditions
because I want to do more in life that be a simple code monkey. Every
monkey can write code, not every monkey can think beyond the next
echo they'll write.
Then there's Wordpress.
I'm still waiting for a day when the code base from Wordpress won't be
given as a negative example but Wordpress runs on a biiig number of
sites.
Do you really really want the opinion of users about a certain RFC?
Put up a pool on the website and promote it on the frontpage, Zend
mailing list, forums and so on. Announce it at least one week before
it runs and run it for two weeks. That should prove accurate enough
from people interested in the language itself. Those who are not
interested shouldn't count anyway.
How that RFC will be implemented is obviously another thing, but
it should be contained by internals not subject to public voting.
But the core needs more contributors.
Yes, I could be one. Why I'm not a contributor to the core? Well
here's a couple of interesting things:
- I haven't learned/used C until now, I've learned Pascal in
highschool, then Java at university and I've done programming
in PHP for seven years now. Not once I've needed, wanted to
learn C (until today that is); - my time outside of work is limited and have to split it up between
many things (like most of you) - I need to learn more PHP, more design patterns, more systems
architecture, more anything that's not related to C but rather
systems, patterns and anything else that I can so that I can
write better software for my employer, keep up with new people
coming after me, provide solutions that save me code, my
employer money and is easy to understand by people that
will maintain after I'll leave my job; - PHP is written in C not in PHP which means that unlike people
that write C all day, for me C is another way of thinking about
things, way different that my main language; - PHP core is not documented properly, people have said
this for a long time now. Even if I'll get a grip of C in the next
month, there's no reason to say I'll be able to write something
for PHP in the next 3-6 months;
Here's another thing that Rasmus said. It sounded sort-of like
this: If companies about a certain size would have at least one
guy that knows C and help out fixing PHP bugs that they
encounter/grow the core then things will be better.
I agree but then there's the cruel reality where such a person
will be useless from business pov for like 99.9% of the time.
Would you hire me at any company to learn C, which I'm
confident I'll do pretty fast, then keep me working on PHP
core?
People who work on Facebook couldn't get their patches in,
for various reasons, but they weren't helped as well to get
them done (https://wiki.php.net/rfc/zendsignals for example)
and you want a random organization to think it could help
PHP when your biggest user can't?
Also there's the issue that since PHP is so simple to pick
up by anyone, there's always plenty of people to replace
you when you start making demands on salary (I think this
applies very well everywhere but mostly to PHP). There
are far fewer companies who actually appreciate good
quality code and maintainability versus: we'll hire 3 cheaper
versions of you and they'll figure it out in the end. And
to be honest, it's quite exhausting to be as productive as
3 people when you also try and to things the right way
in the same amount of time.
I don't think I've said it enough time but there's a thought:
- what if php 5.5 will be the last 5.x branch?
- what if after 5.5 stable release, every core contributor
would take a deserved holiday then get in touch with
community and people like Fabien (Symfony), Matthew
(from ZF), Benjamin (Doctrine), Drupal, Wordrepss, and
so on and so forth, to see what are their needs, where
the language should get the changes and who can help. - what if after that, people would start on PHP 6, not 5.6
and build a better documented core? Not all the features
should get into 6.0, but having a clear roadmap would
help the life of those projects a lot. It would also help
the life of companies and users. Having a clean core
would also mean people will be able to contribute
easier.
You clearly have the expertise now to see what went
wrong in Zend Engine2, make Zend Engine3 better.
It's a big gamble to take, I know, I'm aware of it, but
without a solid foundation you can't build good things
for a long time. And you'll get into issues like the
current ones when you say: X feature will make the
language harder to maintain and so on but because
at the end of the day there's only a bunch of people
that actually understand what happens in the core
and rest are left outside, wondering how much time
can they really invest in making things better.
And in the end, if people who want to add more features
to make the language better, easier to use and develop
better applications should be allowed to get that as they
will also improve the whole lot of people coming after
them.
Thank you! core contributors for the really hard work
you've done so far for PHP, I can't express enough
how much I really appreciate your efforts so far.
Best regards.
Florin Patan
https://github.com/dlsniper
http://www.zend.com/en/yellow-pages#show-ClientCandidateID=ZEND013894
-----Original Message-----
From: Clint Priest [mailto:cpriest@zerocue.com]
Sent: Monday, January 28, 2013 3:15 PM
To: Peter Cowburn
Cc: Zeev Suraski; Pierre Joye; PHP internals
Subject: Re: [PHP-DEV] Voting periodsIf you're still worried about this making it in, don't worry. Nikita
and I have given up, to the determinant of the community.Then please close the voting.
Since there is no "maximum voting period" and 5.5 is not in a feature
freeze yet,
I left the voting open, in case some people decided to read the patch
and change
their minds. I see no reason to close the vote unless I'm required to
do so or the
game is up.I think there's an almost-consensus that voting periods need to be well
defined. Two reasons:
- If you care enough about it you should be able to vote about it within
one or two weeks.- Leaving it open ended gives the RFC proposer too much power. He could
simply end the vote once it happens to reach the necessary majority.So I'd say yes, you're required to end it, either immediately or at most
at the end of the two week boundary.asking for this feature (present in every other modern
language) for 5+ years. I spent two years going through the tedious
RFC
discussion process, wrote the software, Nikita made it even better to
have it
shot down without even reasonable explanations as to why "from most
people."There are two very reasonable explanations, and it's fine you may disagree
with them:
- It makes the language more complex.
- It makes the language more difficult to maintain.
In both cases, the people who opposed it thought that the gain from adding
it doesn't outweigh these loss in complexity and maintenance overhead.Some are resting on the idea that the ROI isn't there just aren't
listening to the
community.The vast majority of the PHP community is a silent one; These people
don't participate here on internals; They don't attend conferences; They
use it - the vast majority of them in a professional manner - and they
picked it because they like it the way it is, not because of what it needs
to become. For every person that subscribes to internals, there's a
thousand (yes, a THOUSAND) people who don't (it's several thousands vs.~5
million). In fact, they're not completely silent. They speak in volumes
- PHP 5.4 is used in less than 1% of the sites using PHP today, and even
the relatively revolutionary 5.3 is still a lot less popular than 5.2.
The new shiny features are not all that interesting for most people.The community that participates in internals isn't necessarily
representative of the community at large.Zeev
Zeev Suraski wrote:
The vast majority of the PHP community is a silent one; These people
don't participate here on internals; They don't attend conferences; They
use it - the vast majority of them in a professional manner - and they
picked it because they like it the way it is, not because of what it needs
to become. For every person that subscribes to internals, there's a
thousand (yes, a THOUSAND) people who don't (it's several thousands vs.~5
million). In fact, they're not completely silent. They speak in volumes
- PHP 5.4 is used in less than 1% of the sites using PHP today, and even
the relatively revolutionary 5.3 is still a lot less popular than 5.2.
The new shiny features are not all that interesting for most people.
I'd like to speak to this as someone involved in WordPress development.
As a whole, despite being a huge project with large amounts of
developers and users, WordPress is pretty under-represented on
php-internals.
One of the big reasons for that is that we're stuck with a lot of
backwards compatibility, both internal and external. We try hard to
ensure that our API to our plugins doesn't break, which unfortunately
has left us with being the go-to project for pointing out bad code. As
much as some may want us to, we're not going to go and rewrite WP in a
day to use new features, so internals discussions aren't that important
at the moment.
We're also stuck with a huge number of hosts still on PHP 5.2:
http://wordpress.org/about/stats/
I'd say it's somewhat of a chicken-and-egg problem, in that WP can't
develop for what's not there, and hosts won't bother upgrading if they
don't have to. We only stopped supporting PHP 4.x when the usage dropped
below 10%, and I'd see the same occurring for 5.2.
To me, I think the best possible thing to do would be to encourage hosts
to upgrade much faster. Rolling APC/Accelerator+ into core would be a
huge part of that from what I see. Backwards compatibility for PHP
itself seems to be pretty good, but it could be better. Hosts are still
reluctant to push existing users forward: Bluehost, Dreamhost, and
GoDaddy all offer 5.3, but none upgrade users automatically; WPEngine
and Page.ly, two large WP-centric hosts, are both on 5.3, since they
know WP won't break on upgrade.
We are making some efforts towards a push for 5.3+. In future releases,
we're planning on introducing some features that would only be enabled
for 5.3+ but none of those have been introduced yet to my knowledge.
Hopefully we can push the hosts enough to get this, but it wouldn't
change much of WordPress internally. Anonymous functions, e.g., are
fairly incompatible with the way we implement the Mediator pattern with
our hooking system. Namespaces might be implemented for new code, but
there's basically zero chance for the existing code base.
--
Ryan McCue
<http://ryanmccue.info/
Zeev Suraski wrote:
The vast majority of the PHP community is a silent one; These people
don't participate here on internals; They don't attend conferences; They
use it - the vast majority of them in a professional manner - and they
picked it because they like it the way it is, not because of what it needs
to become. For every person that subscribes to internals, there's a
thousand (yes, a THOUSAND) people who don't (it's several thousands vs.~5
million). In fact, they're not completely silent. They speak in volumes
- PHP 5.4 is used in less than 1% of the sites using PHP today, and even
the relatively revolutionary 5.3 is still a lot less popular than 5.2.
The new shiny features are not all that interesting for most people.
I'd like to speak to this as someone involved in WordPress development.
As a whole, despite being a huge project with large amounts of
developers and users, WordPress is pretty under-represented on
php-internals.One of the big reasons for that is that we're stuck with a lot of
backwards compatibility, both internal and external. We try hard to
ensure that our API to our plugins doesn't break, which unfortunately
has left us with being the go-to project for pointing out bad code. As
much as some may want us to, we're not going to go and rewrite WP in a
day to use new features, so internals discussions aren't that important
at the moment.We're also stuck with a huge number of hosts still on PHP 5.2:
http://wordpress.org/about/stats/I'd say it's somewhat of a chicken-and-egg problem, in that WP can't
develop for what's not there, and hosts won't bother upgrading if they
don't have to. We only stopped supporting PHP 4.x when the usage dropped
below 10%, and I'd see the same occurring for 5.2.
Hi Ryan. While I understand that level of conservatism, I think it is
somewhat unfounded. The PHP community at large decided to deprecate PHP
4 en masse, and put hosts on notice. It worked, too. The GoPHP5 project
included over 100 projects and 200 hosts that collectively decided it
was time to kill off PHP 4 and move to PHP 5.2. That launched before
the PHP Internals team decided to deprecate PHP 4 [1] , and had been in
the works for a few months prior. And that was even without the support
of heavyweight Wordpress.
If Wordpress announced that it was going to start requiring PHP 5.3 as
of some date 6+ months in the future (and there are advantages to doing
so that don't require major BC breaking rewrites), I think you'd see a
rather significant abandonment of PHP 5.2 among hosts. Many other major
projects already have. I would be rather surprised if Drupal 9 doesn't
require PHP 5.4. (Drupal 8, currently in development, is very solidly
PHP 5.3.)
My point being, the chicken-and-egg problem IS resolvable. PHP userland
developers do have that power if wielded correctly. We just need to
wield it together. We shouldn't let ourselves be pushed around by
cheapskate fly-by-night hosts again.
Disclaimer: Yes, I was the lead organizer of GoPHP5, but not the sole
supporter.
[1] Internals started discussing killing off PHP 4 about a week after
GoPHP5 launched back in 2007. Whether it was entirely coincidental or
there was some causal relationship there is, I suppose, a mystery for
the ages.
--Larry Garfield
Larry Garfield wrote:
Hi Ryan. While I understand that level of conservatism, I think it is
somewhat unfounded. The PHP community at large decided to deprecate PHP
4 en masse, and put hosts on notice. It worked, too. The GoPHP5 project
included over 100 projects and 200 hosts that collectively decided it
was time to kill off PHP 4 and move to PHP 5.2. That launched before
the PHP Internals team decided to deprecate PHP 4 [1] , and had been in
the works for a few months prior. And that was even without the support
of heavyweight Wordpress.
I agree completely personally, I think we need to push much harder for
it and that it would be possible to hit 5.4 by the end of the year.
I was however stating the WordPress party line which is that we don't
need 5.3+ and that we'll only push if we need to. I think it's a shame
personally, but that's what has been decided.
(In my own projects, I target 5.3+ for most projects, but 5.2+ for
projects which need wide deployment, such as SimplePie and Requests.)
If Wordpress announced that it was going to start requiring PHP 5.3 as
of some date 6+ months in the future (and there are advantages to doing
so that don't require major BC breaking rewrites), I think you'd see a
rather significant abandonment of PHP 5.2 among hosts. Many other major
projects already have. I would be rather surprised if Drupal 9 doesn't
require PHP 5.4. (Drupal 8, currently in development, is very solidly
PHP 5.3.)
Here's hoping that Drupal can lead that push with the major hosts. 5.2
on 66% of hosts is ridiculous, and I'm personally sick of having to
backport things to 5.2. GoPHP5 was a fantastic effort and benefited WP
immensely even if we weren't directly involved.
Most of the WordPress committers don't see much advantage with pushing
to 5.3 though, so it's doubtful that we'll lead that charge. (Late
static binding is probably the only thing that they would see as useful,
but WP doesn't use many static methods.)
This all said, the internal dynamics of the WordPress core developers
are always changing, and views are definitely becoming less
conservative. I don't think you'll see us targeting 5.4 any time soon,
but 5.3 is a possibility. I've been talking to a few contacts from the
big hosts in the WP space and it seems like they've all got 5.3
upgrading in the pipeline.
--
Ryan McCue
<http://ryanmccue.info/
If Wordpress announced that it was going to start requiring PHP 5.3 as
of some date 6+ months in the future (and there are advantages to doing
so that don't require major BC breaking rewrites), I think you'd see a
rather significant abandonment of PHP 5.2 among hosts. Many other major
projects already have. I would be rather surprised if Drupal 9 doesn't
require PHP 5.4. (Drupal 8, currently in development, is very solidly
PHP 5.3.)
Here's hoping that Drupal can lead that push with the major hosts. 5.2
on 66% of hosts is ridiculous, and I'm personally sick of having to
backport things to 5.2. GoPHP5 was a fantastic effort and benefited WP
immensely even if we weren't directly involved.
It's great to hear you say that, given that the messaging coming out of
WP at the time was rather hostile. :-)
Most of the WordPress committers don't see much advantage with pushing
to 5.3 though, so it's doubtful that we'll lead that charge. (Late
static binding is probably the only thing that they would see as useful,
but WP doesn't use many static methods.)
I don't know much if anything about WP internals, but in my experience
with Drupal 8 LSB is about the only 5.3 feature that hasn't mattered to
us. Namespaces/PSR-0 and closures have been very helpful. LSB not so
much, but then I'm pleased to say we have very little static method use
in the first place.
This all said, the internal dynamics of the WordPress core developers
are always changing, and views are definitely becoming less
conservative. I don't think you'll see us targeting 5.4 any time soon,
but 5.3 is a possibility. I've been talking to a few contacts from the
big hosts in the WP space and it seems like they've all got 5.3
upgrading in the pipeline.
Maybe next year it will be time for a GoPHP5.5 project. :-) Hopefully by
then WP will have become less conservative enough to join the effort.
--Larry Garfield
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.
As an example, it's looking like PDO is almost a certainty for 3.6. It
will mean some backwards compatibility issues though, so a while ago,
this wouldn't have even been considered.
(Note: I'm not a core committer, mainly due to never having the time to
commit to it, but I am heavily involved in WP development. I'm also
single-handedly responsible for ~10% of the codebase via SimplePie.)
I don't know much if anything about WP internals, but in my experience
with Drupal 8 LSB is about the only 5.3 feature that hasn't mattered to
us. Namespaces/PSR-0 and closures have been very helpful. LSB not so
much, but then I'm pleased to say we have very little static method use
in the first place.
Namespaces don't matter to WordPress really, since it'd only be new code
using them anyway. Changing existing class names would be a huge
internal backwards compatibility break which I doubt will ever happen.
Closures, as I mentioned, don't work well with our action/filter system.
Basically, in order to be able to unregister a callback, you need to
pass in the exact callback that you registered it with; with closures,
this isn't possible unless they're assigned to a variable, which defeats
the purpose.
Maybe next year it will be time for a GoPHP5.5 project. :-) Hopefully by
then WP will have become less conservative enough to join the effort.
Here's hoping. :)
--
Ryan McCue
<http://ryanmccue.info/
hi Ryan,
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
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/
hi Clint, Zeev,
I feel that this is what was done in this particular case, not the other
way around. That what brought me to bring up that subject here in the first
place. This particular RFC was the only RFC where I noticed this weird 'no
sooner than' language, and it seemed intentional to me - given the fact it's
a very controversial feature opposed by most core devs. If we want to change
the default voting period to two weeks, that's fine - but IMHO it should be
for future RFCs after it gets approved.Actually, it was not done on purpose but was mimicking what many other RFC
"vote sections" do, I thought it was the way it was supposed to be done,
see:https://wiki.php.net/rfc/incompat_ctx
https://wiki.php.net/rfc/array_columnIf you're still worried about this making it in, don't worry. Nikita and I
have given up, to the determinant of the community.
This is horribly wrong, totally wrong.
Zeev, for one, was one of them asking to have a 2/3 majority for any
language related RFC. That's what applies to this RFC, and it is, as
of now, accepted. I don't see how the vote is remotely close to a tie.
There is something very bad going on right now. I'd to think how to
solve that as it is the worst thing that can happen to our project,
accepted RFCs being "rejected" because of the pressure.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Zeev, for one, was one of them asking to have a 2/3 majority for any
language
related RFC. That's what applies to this RFC, and it is, as of now,
accepted. I don't
see how the vote is remotely close to a tie.
Are you talking about https://wiki.php.net/rfc/propertygetsetsyntax-v1.2?
There are presently 33 supporteds, 21 opposers. That's less than 2/3
(there would have to be 37 supporters vs. 21 opposers for it to be more
than the needed 2/3). On Wednesday evening it was even less than that.
Zeev
Zeev, for one, was one of them asking to have a 2/3 majority for any
language
related RFC. That's what applies to this RFC, and it is, as of now,
accepted. I don't
see how the vote is remotely close to a tie.Are you talking about https://wiki.php.net/rfc/propertygetsetsyntax-v1.2?
There are presently 33 supporteds, 21 opposers. That's less than 2/3
(there would have to be 37 supporters vs. 21 opposers for it to be more
than the needed 2/3). On Wednesday evening it was even less than that.
I mean more "no matter if it is or not", but the result is not tie
anyway, accepted or not.
I find the way things are being done right now as a bad thing. There
is a time for discussions and argumentations, and there is a time for
votes. Coming in with things like that does not give me a good
feeling. Even if you have a good point about how we should clarify the
voting phase duration.
I am not saying that you do that on purpose or not, but this is
something we should carefully deal with, and not like we were sitting
alone at the Bahnhofstation, if you see what I mean :)
Cheers,
Pierre
@pierrejoye
I mean more "no matter if it is or not", but the result is not tie
anyway, accepted
or not.I find the way things are being done right now as a bad thing. There is
a time for
discussions and argumentations, and there is a time for votes. Coming in
with
things like that does not give me a good feeling. Even if you have a
good point
about how we should clarify the voting phase duration.I am not saying that you do that on purpose or not, but this is
something we
should carefully deal with, and not like we were sitting alone at the
Bahnhofstation, if you see what I mean :)
Agreed.
I'll wait for your proposed improvements to the voting RFC.
Zeev
Hi!
I mean more "no matter if it is or not", but the result is not tie
anyway, accepted or not.
Remember we talked about this while discussing voting? What we have here
is a huge language feature (and, like it or dislike it, it is a big
feature which had a lot of effort, energy and though spent on it, and
also has a lot of consequences for PHP language, which may be good or
bad depending on your POV) balancing more or less on a couple of votes.
And because votes are so close, we get technicalities on which votes may
hinge and possibility for gaming them and possibility of accusing each
other of gaming them, and that doesn't contribute to consensus and
general collaboration. So we need to think about how to make this better.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Stas,
Remember we talked about this while discussing voting? What we have here
is a huge language feature (and, like it or dislike it, it is a big
feature which had a lot of effort, energy and though spent on it, and
also has a lot of consequences for PHP language, which may be good or
bad depending on your POV) balancing more or less on a couple of votes.
And because votes are so close, we get technicalities on which votes may
hinge and possibility for gaming them and possibility of accusing each
other of gaming them, and that doesn't contribute to consensus and
general collaboration. So we need to think about how to make this better.
I think the "making better" shouldn't involve rules. IMHO, if the decision
is so close that it's rejected or accepted on technicalities or gaming,
then it shouldn't be accepted anyway. To me, the vote should be more about
officially verifying consensus, and less about "let the numbers speak". If
it's close enough that rules or whatever against technicalities or gaming
need to come in, then it didn't belong in there in the first place.
But this is also why IMHO voters who don't participate in internals
discussions (at least reading them, if not responding, which is hard to )
shouldn't be allowed to vote. This isn't to limit the voting crowd, but to
increase the consensus on the discussion. The vote should thereby become a
formality. Now, this can lead to bike shedding, but at least it would
result in more voters participating in the discussions (I would hope at
least).
But I definitely agree with you that we do need to make this better...
Anthony
Hi!
Zeev, for one, was one of them asking to have a 2/3 majority for any
language related RFC. That's what applies to this RFC, and it is, as
of now, accepted. I don't see how the vote is remotely close to a tie.
I'm sorry, I am seeing 34/21 result. It's 61% for, 39% against - which
means, it falls short of 2/3 majority. How is it "as of now, accepted"?
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Am 28.01.2013 12:19, schrieb Zeev Suraski:
OK, please put a one week as an option too. To put things in perspective,
elections that effect the fate of billions of people typically end in
24hrs.
But they sometimes require weeks of analysing punch cards ;-)
--
Sebastian Bergmann Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/
Hi,
Le Mon, 28 Jan 2013 11:22:52 +0200, Zeev Suraski a écrit :
Regardless, an
‘open ended’
voting period is unacceptable IMHO.
I agree with that. An update of the voting rfc (https://wiki.php.net/rfc/
voting) should be made.
However one week only seems a little shorter in my opinion to validate
changes that "will affect millions of people". There's times in the year
when we are most AFK (summer vacations, christmas, etc...) and as you
point that there can be "a specific point in time where the vote happens
to be in favor with what the proposer wanted", there also can have a
specific period in the year to make a rfc pass easier due to the lack of
voters (perhaps my mind is twisted but i've already seen this trick in
politics so... ;-).
I'm not sure how long we should make the vote duration but i think that,
like the discussion period, there shoud be a minimum 2 weeks between the
vote opening and it's closing.
My 2 cents,
regards,
Bruno
My suggestion is for voting periods to be limited to one week, regardless
of the topic. It should be more than enough. Regardless, an ‘open ended’
voting period is unacceptable IMHO.
Whatever the voting period is, IMHO the most important thing would be to
have the person opening the vote set a mandatory voting end date in the
announcement + RFC itself, no matter how long it will be (to be
discussed seperately)
Greetings,
Florian
--e89a8fb1fbd85c066a04d455d2d7
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printableThe specific case in point is
https://wiki.php.net/rfc/propertygetsetsyntax-v1.2 - which while has more
supporters than opposers, consistent fell short of the 2/3 majority it
needs to be approved. The vote should have ended on Wednesday =E2=80=93 4 =
days
ago, but for some reason it=E2=80=99s still open. It=E2=80=99s time to clo=
se it.
I agree. We need a defined period for voting. The past RFCs have seen
very short voting periods to very long, depending on what the RFC creator
wanted and usually worked in his favor. To make it more objectiv and
actually concentrate on code instead of votings I tihnk a 1 week or 2
week period after calling for votes is okay and shouldn't be able to
be extended.
Concerning the property syntax, I agree that this vote should be closed
already.
David