On Tue, Nov 23, 2010 at 12:24 PM, Zeev Suraski <z...@zend.com> wrote:
> > > > -----Original Message----- > > From: Derick Rethans [mailto:der...@php.net] > > Sent: Tuesday, November 23, 2010 11:58 AM > > To: Felipe Pena > > Cc: internals > > Subject: Re: [PHP-DEV] Hold off 5.4 > > > > On Mon, 22 Nov 2010, Felipe Pena wrote: > > > > > Given the current state of trunk, I think 5.4 release process should > > > not begin tomorrow (alpha or whatever other status). There are > > > numerous identified issues that we need to fix before even think to > > > begin with a release. For example: > > > > > > - type hinting (or strict hinting) > > > - no consensus > > > - the RFCs are unclear > > > - BC break introduced > > > . classes named as any of the type hint scalar types do not work > > > anymore aka class int {} > > > > Yeah, there is a slight hint of a BC break in case you have a class named > "int" > > or "float" etc. But there is: > > http://uk.php.net/manual/en/userlandnaming.tips.php > > For the record, I'm still very uncomfortable with this new language syntax > - even if it's a no-op right now. > How do we document it? As what? > Johannes wrote a blogpost about that: http://schlueters.de/blog/archives/148-More-on-scalar-type-hints-in-PHP-trunk.html and we didn't even discussed the current implementations, because the discussion was halted until the new revised patch is complete. which seems will be rolled out without further discussion. > Are we effectively going to create the original type checking > implementation, but in a separate component people would have to install - > thereby creating two very different flavors of PHP? > > Regarding the alpha release, I think there are two key issues here: > > 1. Does this alpha mean anything at all. Some, myself included, don't > feel comfortable about the state of certain things in the current codebase > (example given above). Are we all in sync that even if a certain feature > makes it into the alpha, it doesn't mean that it won't be removed or be > severely modified in an upcoming beta/GA? Is it clear it has no > implications on when the final release would be? That is, at least, the way > I perceive alpha releases. In which case it's not exactly clear to me what > the benefits of releasing an Alpha in this day and age for PHP - where we > have snapshots every few hours. We need to have a very clear understanding > of what this does or doesn't mean, and make sure we communicate it properly > to the users. > we shouldn't release something, that at least the core devs are agree on. imo. > > 2. Not strictly related to this particular 5.4 effort, but I think that > recent months have shown that we desperately need a decision making process. > Somewhat more formalized and logical than anybody who happens to be > subscribed to internals@ being able to put things to a vote and vote on > them. This is one tough cookie - but I think we have to tackle it. My > personal belief is that people on internals@ are biased towards the very > top end of the userbase pyramid, and we have to find a way to represent the > views of the PHP userbase at large. > Agree. But I think that there are more than one kind of voting that we need. - what does the avarage php user thinks about something. (adding/removing a feature, who would use that, php.net redesign, etc.). - what does the cms/framework dev people think about something (there are many feature, which didn't useful directly to the end-users, but they can get good use of it through a framework: late static binding, namespaces, annotations, etc.) - what does our vendors think about something (debian, redhat, etc. they can provide useful feedback about configuration/maintenance, release policy kind of polls) - what does a php contributor(documentation, qa, website, etc. so involved in the php project) thinks about something (for example polls about our infrastructures, or standards, etc.) - what does a pecl contributor thinks about something (adding a new hook into the core, etc., changing internal API, etc.) - what does a php-src contributor thinks about something (hardcore stuff, adding new features by design/performance/maintainability wise, etc. ) and maybe it would be a good idea to restrict the poll/vote for the active members. so if somebody was once involved in the project, but lost time or interest, and didn't followed or contributed to that part of the project, that those people to bias the vote without a good understanding about the actual problem/situation. but of course that's only my 2 cents. Tyrael
