Re: Voting periods

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 periods > > > > > > On 1/28/2013 6:12 AM, Peter Cowburn wrote: > > > On 28 January 2013 12:03, Clint Priest <cpriest@zerocue.com> wrote: > > >> 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 think there's an almost-consensus that voting periods need to be well > defined. Two reasons: > > 1. If you care enough about it you should be able to vote about it within > one or two weeks. > 2. 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: > > 1. It makes the language more complex. > 2. 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 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > Lazare INEPOLOGLOU Ingénieur Logiciel