Re: [PHP-DEV] Purpose of voting
On Jan 28, 2013, at 2:14 PM, Anthony Ferrara ircmax...@gmail.com wrote: Hey all, After reading the Voting Periods email thread, I'm left wondering a simple question (which has a difficult answer): What should we be voting on when voting on an RFC: on the RFC proposed feature, or on the patch itself? Personally, I'm discussing/voting on the feature. We do tend to combine our discussions, but voting seems to be directly for the proposed feature. I don't necessarily disagree with this approach, as we tend to hash out the implementation during the discussions. It might save RFC authors a lot of time and keyboard taps if we discussed/voted on a feature prior to discussing implementation. This could open the door for a flood of feature requests in the form of RFCs, but I don't believe that would happen. One of the advantages of combining the patch(es) with an RFC is it shows the author has put forth an effort in thinking the idea through. That said, a rule of thumb (or official rule) that RFC authors should provide a patch once the feature has been approved might work. In the end, separating the two would end up saving the RFC's author and this list time as to whether a feature should be considered. However, there are times where the implementation could change the outcome of the feature vote itself. I've always approached it as we're voting for the concept (and details) provided in the RFC. But it appears that other people have been voting on the specifics of the attached patch (so theoretically an RFC could be rejected entirely because some people don't like part of the implementation in C, but are fine with the PHP details). I'll leave out my opinion (and justification) for now, I'm curious what you all think... Thoughts? Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Purpose of voting
Hi! What should we be voting on when voting on an RFC: on the RFC proposed feature, or on the patch itself? Either, or both, depending on the RFC and the intent of the author. Note that since there's rarely competing teams/patches on the same feature, accepting the RFC means also accepting the approach proposed by the team doing it, otherwise it's meaningless - if we accept the idea, but not implementation, what the use would be for the idea which has nobody to implement it? -- 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
Re: [PHP-DEV] Purpose of voting
hi, On Mon, Jan 28, 2013 at 8:14 PM, Anthony Ferrara ircmax...@gmail.com wrote: Hey all, After reading the Voting Periods email thread, I'm left wondering a simple question (which has a difficult answer): What should we be voting on when voting on an RFC: on the RFC proposed feature, or on the patch itself? I've always approached it as we're voting for the concept (and details) provided in the RFC. But it appears that other people have been voting on the specifics of the attached patch (so theoretically an RFC could be rejected entirely because some people don't like part of the implementation in C, but are fine with the PHP details). I'll leave out my opinion (and justification) for now, I'm curious what you all think... Thoughts? We do not vote on RFC for features/change without patch(es). However I could imagine a kind of poll to see if a complex feature is worse the effort to implement it. It can be very frustrated and demotivating to spend literally days on something that will be rejected. 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] Purpose of voting
What should we be voting on when voting on an RFC: on the RFC proposed feature, or on the patch itself? I think it should be exclusively on the concept. We never vote about code changes anywhere - including when we refactor existing parts. Why would we vote about the implementation here? The concept is the important part, not the implementation. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Purpose of voting
On Mon, Jan 28, 2013 at 12:53 PM, Zeev Suraski z...@zend.com wrote: What should we be voting on when voting on an RFC: on the RFC proposed feature, or on the patch itself? I think it should be exclusively on the concept. We never vote about code changes anywhere - including when we refactor existing parts. Why would we vote about the implementation here? The concept is the important part, not the implementation. Implementation can be a HUGE factor in whether I vote yes or no. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Purpose of voting
-Original Message- From: Levi Morrison [mailto:morrison.l...@gmail.com] Sent: Monday, January 28, 2013 10:04 PM To: Zeev Suraski Cc: Anthony Ferrara; internals@lists.php.net Subject: Re: [PHP-DEV] Purpose of voting On Mon, Jan 28, 2013 at 12:53 PM, Zeev Suraski z...@zend.com wrote: What should we be voting on when voting on an RFC: on the RFC proposed feature, or on the patch itself? I think it should be exclusively on the concept. We never vote about code changes anywhere - including when we refactor existing parts. Why would we vote about the implementation here? The concept is the important part, not the implementation. Implementation can be a HUGE factor in whether I vote yes or no. Fair enough, it has next to zero effect on mine - unless we're dealing with something extremely fundamental. Otherwise, why not put each and every commit up for a vote? Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Purpose of voting
On Mon, Jan 28, 2013 at 8:14 PM, Anthony Ferrara ircmax...@gmail.comwrote: Hey all, After reading the Voting Periods email thread, I'm left wondering a simple question (which has a difficult answer): What should we be voting on when voting on an RFC: on the RFC proposed feature, or on the patch itself? I've always approached it as we're voting for the concept (and details) provided in the RFC. But it appears that other people have been voting on the specifics of the attached patch (so theoretically an RFC could be rejected entirely because some people don't like part of the implementation in C, but are fine with the PHP details). I'll leave out my opinion (and justification) for now, I'm curious what you all think... Thoughts? Anthony what I've seen this far is if an rfc includes a patch accepting the rfc means that we accept the patch to be merged. usually that also means that the change will be introduced into the lowest possible version where appropriate (eg, now 5.3 is in basically critical bugfix/security fixes only mode, or how much of a BC break is the proposed change, etc.). I think that in some cases having a vote without an impelentation could be useful. I see two common scenarios: 1. voting before a major task where are multiple options are present (should we use utf-8 or utf-16 internally for the unicode support for example, the RFC would show the pros and cons, some benchmarks, maybe some POC, but not a full fledged implementation because nobody would dare to cook that up until he/she feels that it is backed by a majority of the voters(it can still fail on the implementation and it would require another vote before merging ofc,). 2. voting where the implementation doesn't really an issue, but we want to get the common vision/agreement about some change (should we drop support of archaic/less used platform/compiler/etc.). I also think that listing the potential BC break of an RFC and the suggested target version should a mandatory part of every RFC. I'm almost sure that the accessor RFC would have won over the votes if it would have explicitly targeted the next after 5.5 version (or if it could have reached the current status like 2-3 months ago). Just my 2 cents of course. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] Purpose of voting
On Mon, 28 Jan 2013, Anthony Ferrara wrote: I've always approached it as we're voting for the concept (and details) provided in the RFC. But it appears that other people have been voting on the specifics of the attached patch (so theoretically an RFC could be rejected entirely because some people don't like part of the implementation in C, but are fine with the PHP details). I'll leave out my opinion (and justification) for now, I'm curious what you all think... Thoughts? Both the idea and implementation needs to be sound. If not, I vote no (and that also means no when it makes APC's life harder). cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Purpose of voting
2013/1/28 Zeev Suraski z...@zend.com: What should we be voting on when voting on an RFC: on the RFC proposed feature, or on the patch itself? I think it should be exclusively on the concept. We never vote about code changes anywhere - including when we refactor existing parts. Why would we vote about the implementation here? Just to +1 Zeev's opinion here. It's perfectly valid to accept an RFC and comment on the implementation on what should be improved or what sucks in it. If one is voting no mostly because of the implementation, then I would say that there is a lack of information in the voting process when saying no. (No why... ?) Side node: whatever the formal process we will use we will always have to be flexible enough to listen to each other and not falling into bureaucracy too much. Patrick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Purpose of voting
2013/1/28 Derick Rethans der...@php.net: Both the idea and implementation needs to be sound. If not, I vote no (and that also means no when it makes APC's life harder). This is a bit unfair. APC is just one byte code caching mechanism out there, even if it's the mostly used or most performing one (and even the one I prefer by far). If it was part of the core, then it would make more sense voting this way. -- Patrick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Purpose of voting
On Mon, Jan 28, 2013 at 11:11 PM, Patrick ALLAERT patrickalla...@php.netwrote: 2013/1/28 Zeev Suraski z...@zend.com: What should we be voting on when voting on an RFC: on the RFC proposed feature, or on the patch itself? I think it should be exclusively on the concept. We never vote about code changes anywhere - including when we refactor existing parts. Why would we vote about the implementation here? Just to +1 Zeev's opinion here. It's perfectly valid to accept an RFC and comment on the implementation on what should be improved or what sucks in it. If one is voting no mostly because of the implementation, then I would say that there is a lack of information in the voting process when saying no. (No why... ?) Side node: whatever the formal process we will use we will always have to be flexible enough to listen to each other and not falling into bureaucracy too much. Patrick voting no based on the implementation would be that bad if the more voters could participate in the discussion phase, as that is where those problems should be laid out and addressed. as Client also said, knowing why a person voted no is much easier to bear for the author even if he doesn't agree with those. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] Purpose of voting
On Mon, Jan 28, 2013 at 10:24 PM, Ferenc Kovacs tyr...@gmail.com wrote: On Mon, Jan 28, 2013 at 11:11 PM, Patrick ALLAERT patrickalla...@php.net wrote: It's perfectly valid to accept an RFC and comment on the implementation on what should be improved or what sucks in it. If one is voting no mostly because of the implementation, then I would say that there is a lack of information in the voting process when saying no. (No why... ?) voting no based on the implementation would be that bad if the more voters could participate in the discussion phase, as that is where those problems should be laid out and addressed. as Client also said, knowing why a person voted no is much easier to bear for the author even if he doesn't agree with those. In this particular case, a lot of people felt that the concept itself was undesirable. Particularly memorable was the crass flaming of Stas. Also I think the approach of defining specifics while the general concept was under question, was misguided to say the least. Feedback was ignored or forewarned because it didn't fit in the narrow cast you provided. People voting no based on the implementation were the least of your worries. Arpad
