Hello Steph,

speakin as a looser - we should keep what we just decided on and do it.
Do it as in work on it. As in code. As in no more politics for the moment.

marcus

Sunday, September 16, 2007, 6:12:14 PM, you wrote:

Hi Ilia,

If it helps any we can count everything else in and just look at the ones
that failed:

No quorum:

Switch for disabling/enabling materialized cursors in mysqli - 25/28 no
vote, 3 positive votes
Merge the GCC 4 -fvisibility patch - 20/28 no vote, 7 positive votes, 1
negative vote

Voting anomalies:

Introduce concept of "strict classes" that do not permit dynamic property
creation - 12/28 no vote, 12 positive, 4 negative
Implement David's Circular Garbage collection patch - 13/28 no vote, 11
positive, 4 negative
Link phar extension from PECL into core - 12/28 no vote, 11 positive, 5
negative

Definitely out:

Remove safe_mode, register_globals and magic_quotes - 6/28 no vote, 4
positive, 18 negative

I think it's probably fair to say that the mysqli-specific issue shouldn't
be on this agenda in the first place, and the GCC 4 patch most likely failed
because those that aren't directly affected by it don't understand it enough
to vote over it.

That leaves just three features that fail under your voting system but might
pass under others. The question is whether those three are up for debate
now, or later.

• Steph

----- Original Message -----
From: "Ilia Alshanetsky" ilia@prohost.org
To: "Lukas Kahwe Smith" mls@pooteeweet.org
Cc: "Stanislav Malyshev" stas@zend.com; "PHP Developers Mailing List"
internals@lists.php.net
Sent: Sunday, September 16, 2007 4:31 PM
Subject: Re: [PHP-DEV] PHP 5.3 Suggested Feature List (Summary)

Ilia Alshanetsky wrote:

NP ;-) Btw the detailed breakdown of the votes is available here
http://bb.prohost.org/53Features.pdf

I have taken the data from this PDF and slightly reworked things [1] so
that its easy to see which topics got more attention with votes than
others. I think its critical to understand that several items were hard
for the general community to vote on because of lack of expertise (as
noted in several votes). As such I find it questionable to apply a +10
threshold on all items.

Furthermore I ask everybody to review if his vote was interpreted as
they wanted in Ilia's PDF. Some people made their votes conditional,
which is not supported by the formats chosen for tallying up the votes.

Lukas has a good point about the "0" votes, however if there are niche
features most people don't really care/know about that in itself means
that there is not much support for said functionality. IMHO the point of
the vote was to identify KEY features general community (developers &
users) would like to see in 5.3, not to introduce feature creep, which
re-enumeration of the vote does to some extent, please keep that mind
when reviewing the #s. Additionally, remember that 5.3 is a "minor"
release and is not the most appropriate platform for "anything &
everything" inclusion.

Ilia Alshanetsky

--

Best regards,
Marcus

Hey all,

So while I think making list and voting is great, I think we shouldn't
replace good old per-case consideration and discussion with arithmetics.
If we have clear winners and losers, it's fine, but in between we still
need to hear the case.

I couldn't agree with this more. The vote was very helpful in
narrowing the field of debate: Now there's only three things to be
discussed and work can start on making ready the majority of 5.3.
However, there were a lot of no-votes on those topics due to lack of
information and further discussion would lead to a more informed
decision. There probably should be a separate round of voting on just
those three issues after some discussion.

Speaking in particular about the GC :-), I know there hasn't been
widespread review of it (only those who have downloaded my working
copy from a separate repository) and I certainly don't think everyone
who voted on it have actually played around with it.

My personal opinion is that it is ready for 5.3 and should be put into
5.3. It is stable, end-users will not be affected unless they want to
use it, extension writers should not even be affected, there is no
performance degradation and it would help make PHP a much more
credible language to use for anything that runs for longer than a web
script.

I've been bumping the prerequisite macro patch thread for so long to
no avail that it's starting to get embarrassing. Could people take
another look at it and tell me whether a vote between the two versions
of it would now be appropriate?

David

Pierre skrev:

Only ext/mysql and ext/mysqli use it. PDO is somehow "planed" but I
have serious doubts about the motivations of mysql to ever support pdo
like they support other generic connectors (see .net...).

The first posts on the net from MySQL-people talked about mysqli first,
PDO second and not the old mysql-functions at all.

And the facts are: mysql first, then mysqli and pdo "if it works well
when you are done".

I think that if the PHP community really starts commit to PDO, like in
teaching PDO first to beginners and using PDO for normal examples in
blog posts and on book pages, the people at MySQL will make sure that
PDO_MYSQL moves to the new lib as well.

Well, it is already the case, did not change anything.

Also, is it not George S, Ilia and Wez that are listed as mainters of
PDO_MYSQL?

Yes, as they do all the initial work. What's the point? Mysql was not
a maintainer/initiator of any of the .net db layers (or any other
language).

--Pierre