Hello all.
I'd like to express my feelings on the "let's-enable-it-by-default" mood that has emerged lately.
Extensions enabled by default in 5.2:
ctype
date
dom
filter
hash
iconv
json
libxml
pcre
PDO
pdo_sqlite
posix
Reflection
session
SimpleXML
SPL
SQLite
standard
tokenizer
xml
xmlreader
xmlwriter
Total: 22 extensions
Extensions enabled by default in 5.3:
ctype
date
dom
ereg
fileinfo - new, untested.
filter
hash
iconv
json
libxml
pcre
PDO
pdo_sqlite
Phar - new, untested
posix
Reflection
session
SimpleXML
SPL
SQLite
sqlite3 - new, untested
standard
tokenizer
xml
xmlreader
xmlwriter
Total: 26 extensions
All of the newly enabled extension are still in development and none of them
are known to be stable enough to be even included into the core, but for
some weird reason they got even enabled by default (i.e. officially recommended).
So we now have 3 (three) SQLite extensions, all of them too slow to be used in real
life (because SQLite itself is slow), two PDO extensions (unmaintained, known to cause
crashes), json (author's gone for a burton; stability and necessity is arguable),
fileinfo extension with no tests and poorly written bundled lib known to cause crashes
and we in fact officially recommend them by enabling them all by default.
So why should we even bother disabling something?
Let's enable everything by default, most of the users use --disable-all anyways!
I can agree that disabling something that was already enabled in 5.2 might create
some confusion, but why enable scarcely created extensions by default, especially if
they are known to cause lost of obscure problems in the past (like Phar)?
I mean completely no offense to the developers of these extensions, but
I would like them (extensions) to be thoroughly tested and mature first,
after that we can discuss the question of adding them to the core.
And no, they must not be enabled by default unless they bring some extra-useful
functionality that the engine lacks (like SPL and reflection do).
--
Wbr,
Antony Dovgal
Antony Dovgal wrote:
Hello all.
I'd like to express my feelings on the "let's-enable-it-by-default" mood
that has emerged lately.Extensions enabled by default in 5.2:
ctype
date
dom
filter
hash
iconv
json
libxml
pcre
PDO
pdo_sqlite
posix
Reflection
session
SimpleXML
SPL
SQLite
standard
tokenizer
xml
xmlreader
xmlwriterTotal: 22 extensions
Extensions enabled by default in 5.3:
ctype
date
dom
ereg
fileinfo - new, untested.
filter
hash
iconv
json
libxml
pcre
PDO
pdo_sqlite
Phar - new, untested
posix
Reflection
session
SimpleXML
SPL
SQLite
sqlite3 - new, untested
standard
tokenizer
xml
xmlreader
xmlwriterTotal: 26 extensions
All of the newly enabled extension are still in development and none of
them are known to be stable enough to be even included into the core,
but for some weird reason they got even enabled by default (i.e.
officially recommended).So we now have 3 (three) SQLite extensions, all of them too slow to be
used in real life (because SQLite itself is slow),
This is just your opinion. SQLite is fast enough for mainly static data
and its zero configuration setup makes it an ideal DB solution. Using
MySQL for the sake of MySQL isn't always the answer.
Regarding there being three extensions, sqlite uses libsqlite v2. I'd
remove it in a heartbeat if libsqlite v3 could read the database format
but that currently isn't the case. I'm looking to it now to see if
pulling out the db is possible.
ext/pdo_sqlite and ext/sqlite3 use the same underlying lib so its just
another wrapper but without the PDO crap on top.
two PDO extensions
(unmaintained, known to cause crashes), json (author's gone for a
burton; stability and necessity is arguable), fileinfo extension with no
tests and poorly written bundled lib known to cause crashes
and we in fact officially recommend them by enabling them all by default.So why should we even bother disabling something?
Let's enable everything by default, most of the users use --disable-all
anyways!I can agree that disabling something that was already enabled in 5.2
might create some confusion, but why enable scarcely created extensions
by default, especially if they are known to cause lost of obscure
problems in the past (like Phar)?I mean completely no offense to the developers of these extensions, but
I would like them (extensions) to be thoroughly tested and mature first,
after that we can discuss the question of adding them to the core.
And no, they must not be enabled by default unless they bring some
extra-useful functionality that the engine lacks (like SPL and
reflection do).
If you have ideas on testing without enabling them or bundling in the
build please do share. It's a chicken and egg situtation imho.
Scott
ext/pdo_sqlite and ext/sqlite3 use the same underlying lib so its just
another wrapper but without the PDO crap on top.
I know, I know.
But why enable it by default (as well as PDO_SQLITE)?
What's so extremely useful in this extension that every user needs it?
If you have ideas on testing without enabling them or bundling in the
build please do share. It's a chicken and egg situtation imho.
Testing doesn't require enabling it by default.
In fact, it doesn't even require putting the extension in the core,
though this surely increases the the amount of feedback.
Developers should test their extensions, not users.
--
Wbr,
Antony Dovgal
Antony Dovgal wrote:
ext/pdo_sqlite and ext/sqlite3 use the same underlying lib so its just
another wrapper but without the PDO crap on top.I know, I know.
But why enable it by default (as well as PDO_SQLITE)? What's so
extremely useful in this extension that every user needs it?
The zero configuration aspect, the ability to just throw up a database
in place of your own over complicated storage format. Sure all hosts
have MySQL but if you're shipping a product then sometimes its simpler
to just bundle a SQLite DB.
Clientside apps are also moving forward with SQLite, Firefox 3.0, Google
Gears, Adobe AIR and just about every Apple product. I've been writing
PHP scripts to start using the data.
I'm happy to disable PDO by default and have you force it on like mysql
or any of the others.
If you have ideas on testing without enabling them or bundling in the
build please do share. It's a chicken and egg situtation imho.Testing doesn't require enabling it by default.
In fact, it doesn't even require putting the extension in the core,
though this surely increases the the amount of feedback.
Developers should test their extensions, not users.
Yep, we're already using it here in several applications and I have a
few side projects using it.
Test coverage was good, about 80%. I'll be doing more before alpha 2.
Scott
I know, I know.
But why enable it by default (as well as PDO_SQLITE)? What's so
extremely useful in this extension that every user needs it?The zero configuration aspect, the ability to just throw up a database
in place of your own over complicated storage format. Sure all hosts
have MySQL but if you're shipping a product then sometimes its simpler
to just bundle a SQLite DB.
None of this requires enabling it by default.
--
Wbr,
Antony Dovgal
I know, I know.
But why enable it by default (as well as PDO_SQLITE)? What's so extremely
useful in this extension that every user needs it?The zero configuration aspect, the ability to just throw up a database in
place of your own over complicated storage format. Sure all hosts have MySQL
but if you're shipping a product then sometimes its simpler to just bundle a
SQLite DB.None of this requires enabling it by default.
One of the reason of the PHP success is its feature richness.
ISP, good or bad, enables what we enable. You can see that in the
extension usage statistic (from nexen.net). They have to be taken with
a bit of salt but they represent a good way to see what actually
happens out there. I heard solutions like "educating the ISPs" and
seriously that's a sweet dream and may not reflect their needs.
An extension not enabled by default is often not used for this exact
reason: it is not enabled by default. So my thoughts are really
simple, unless disable-all is used, enable everything possible as long
as the deps are found (or if there is no dep).
Cheers,
Pierre
One of the reason of the PHP success is its feature richness.
Since when is "feature richness" == "Sqlite3 must be enabled by default"?
ISP, good or bad, enables what we enable.
Not true.
--
Wbr,
Antony Dovgal
Pierre Joye wrote:
ISP, good or bad, enables what we enable. You can see that in the
extension usage statistic (from nexen.net). They have to be taken with
a bit of salt but they represent a good way to see what actually
happens out there. I heard solutions like "educating the ISPs" and
seriously that's a sweet dream and may not reflect their needs.An extension not enabled by default is often not used for this exact
reason: it is not enabled by default. So my thoughts are really
simple, unless disable-all is used, enable everything possible as long
as the deps are found (or if there is no dep).
As a maintainer of a distributed open source PHP application, I concur
with this 1000 fold. If it is not enabled by default, we can not use it
in Phorum. We have found that only extensions that the PHP configure
includes by default are available on 99% of ISP's servers out there.
So, if json is not on by default, for example, we can't use it.
--
Brian Moon
Senior Web Engineer
When you care enough to spend the very least.
http://dealnews.com/
Hi folks,
Am 01.08.2008 um 12:30 schrieb Antony Dovgal:
ext/pdo_sqlite and ext/sqlite3 use the same underlying lib so its
just another wrapper but without the PDO crap on top.I know, I know.
But why enable it by default (as well as PDO_SQLITE)? What's so
extremely useful in this extension that every user needs it?
FWIW: In TYPO3 5.0 we rely on PDO_SQLITE and use it as the default
database directly after the installation of TYPO3. Not because SQLite
is such a performant database, but rather because we can use it
without having to ask the user for any configuration / credentials.
Later on the user has the opportunity to move her data into a more
sophisticated database such as MySQL or Oracle.
So from our point of the universe: Please keep PDO_SQLITE enabled, it
makes our lives much easier.
Cheers,
Robert
Hello Robert,
Friday, August 1, 2008, 12:44:20 PM, you wrote:
Hi folks,
Am 01.08.2008 um 12:30 schrieb Antony Dovgal:
ext/pdo_sqlite and ext/sqlite3 use the same underlying lib so its
just another wrapper but without the PDO crap on top.I know, I know.
But why enable it by default (as well as PDO_SQLITE)? What's so
extremely useful in this extension that every user needs it?
FWIW: In TYPO3 5.0 we rely on PDO_SQLITE and use it as the default
database directly after the installation of TYPO3. Not because SQLite
is such a performant database, but rather because we can use it
without having to ask the user for any configuration / credentials.
Later on the user has the opportunity to move her data into a more
sophisticated database such as MySQL or Oracle.
So from our point of the universe: Please keep PDO_SQLITE enabled, it
makes our lives much easier.
Stuff like this is the exact reason we enabled SQLite by default from the
beginning. We discussed it as soon as SQLite was created and all agreed
that we should have at least one database always enabled.
Now if Type3, one of the largest users of PHP, requires PDO_SQLite, we
should definitively enable it by default.
And actually my opinion is that there hardly is a reason for an extension
to be in core if it is not enabled by default.
Best regards,
Marcus
On Friday 01 August 2008 5:44:20 am Robert Lemke wrote:
FWIW: In TYPO3 5.0 we rely on PDO_SQLITE and use it as the default
database directly after the installation of TYPO3. Not because SQLite
is such a performant database, but rather because we can use it
without having to ask the user for any configuration / credentials.
Later on the user has the opportunity to move her data into a more
sophisticated database such as MySQL or Oracle.So from our point of the universe: Please keep PDO_SQLITE enabled, it
makes our lives much easier.Cheers,
Robert
FWIW: Drupal is in the process of moving in the same direction, with our
database layer moving over to PDO with intent to ship with a SQLite database
for the installer. Having at least that minimum baseline of database
capability, however fast or slow it may be, is critical.
--
Larry Garfield
larry@garfieldtech.com
ext/pdo_sqlite and ext/sqlite3 use the same underlying lib so its
just another wrapper but without the PDO crap on top.I know, I know.
But why enable it by default (as well as PDO_SQLITE)? What's so
extremely useful in this extension that every user needs it?
It means that every PHP developer can expect their clients servers to
support an SQL backend.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
Am 01.08.2008 um 12:11 schrieb Antony Dovgal:
Hello all.
I'd like to express my feelings on the "let's-enable-it-by-default"
mood that has emerged lately.Extensions enabled by default in 5.2:
8<Total: 22 extensions
Extensions enabled by default in 5.3:
8<Total: 26 extensions
8<
Which reminds me I was meaning to ask... Why is ext/xsl not enabled by
default?
David
I am not sure about SQLite being "always slow", it works rather well
in some instances. That said, I agree with the general gist of this e-
mail about reviewing closely the extensions that are enabled by
default. That said, most people get their PHP from a distributions,
which typically make their own decisions about what to include or not.
The people who compile by hand for whom this would matter, probably
should know what they need or not anyway.
Hello all.
I'd like to express my feelings on the "let's-enable-it-by-default"
mood that has emerged lately.Extensions enabled by default in 5.2:
ctype
date
dom
filter
hash
iconv
json
libxml
pcre
PDO
pdo_sqlite
posix
Reflection
session
SimpleXML
SPL
SQLite
standard
tokenizer
xml
xmlreader
xmlwriterTotal: 22 extensions
Extensions enabled by default in 5.3:
ctype
date
dom
ereg
fileinfo - new, untested.
filter
hash
iconv
json
libxml
pcre
PDO
pdo_sqlite
Phar - new, untested
posix
Reflection
session
SimpleXML
SPL
SQLite
sqlite3 - new, untested
standard
tokenizer
xml
xmlreader
xmlwriterTotal: 26 extensions
All of the newly enabled extension are still in development and none
of them are known to be stable enough to be even included into the
core, but for some weird reason they got even enabled by default
(i.e. officially recommended).So we now have 3 (three) SQLite extensions, all of them too slow to
be used in real life (because SQLite itself is slow), two PDO
extensions (unmaintained, known to cause crashes), json (author's
gone for a burton; stability and necessity is arguable), fileinfo
extension with no tests and poorly written bundled lib known to
cause crashes
and we in fact officially recommend them by enabling them all by
default.So why should we even bother disabling something?
Let's enable everything by default, most of the users use --disable-
all anyways!I can agree that disabling something that was already enabled in 5.2
might create some confusion, but why enable scarcely created
extensions by default, especially if they are known to cause lost of
obscure problems in the past (like Phar)?I mean completely no offense to the developers of these extensions,
but I would like them (extensions) to be thoroughly tested and
mature first, after that we can discuss the question of adding them
to the core.
And no, they must not be enabled by default unless they bring some
extra-useful functionality that the engine lacks (like SPL and
reflection do).--
Wbr, Antony Dovgal--
Ilia Alshanetsky
Hi,
Antony Dovgal wrote:
Extensions enabled by default in 5.3:
ctype
date
dom
ereg
fileinfo - new, untested.
filter
hash
iconv
json
libxml
pcre
PDO
pdo_sqlite
Phar - new, untested
posix
Reflection
session
SimpleXML
SPL
SQLite
sqlite3 - new, untested
standard
tokenizer
xml
xmlreader
xmlwriterTotal: 26 extensions
I don't see any reason to not include mbstring in this list.
Moriyoshi
I mean completely no offense to the developers of these extensions, but
I would like them (extensions) to be thoroughly tested and mature first,
after that we can discuss the question of adding them to the core.
I think alpha stage is a time where they can be tested and depending on
feedback we can decide how to proceed. I assume most people do a
configure and pick their favorite extensions and it's all they test. By
enabling we at least compile-test and run-tests.php-test them on
multiple platforms.
In general I lean towards the "why bundle it if it's not enabled" side.
But this is a good discussion and probably I change my opinion on that.
johannes
I can agree that disabling something that was already enabled in 5.2 might create
some confusion, but why enable scarcely created extensions by default, especially if
they are known to cause lost of obscure problems in the past (like Phar)?
See http://bugs.php.net/bug.php?id=45613 for example.
Who would have thought that there are multithreaded web-servers, eh?
I'm going to disable ext/phar before alpha2.
You've been warned.
--
Wbr,
Antony Dovgal
hi,
I can agree that disabling something that was already enabled in 5.2 might
create some confusion, but why enable scarcely created extensions by
default, especially if they are known to cause lost of obscure problems in
the past (like Phar)?See http://bugs.php.net/bug.php?id=45613 for example.
Who would have thought that there are multithreaded web-servers, eh?I'm going to disable ext/phar before alpha2.
You've been warned.
Are you saying that you are going to disable every extension having
bugs? That sounds weird, besides that only the RMs has the last word
on that.
Cheers,
Pierre
See http://bugs.php.net/bug.php?id=45613 for example.
Who would have thought that there are multithreaded web-servers, eh?I'm going to disable ext/phar before alpha2.
You've been warned.Are you saying that you are going to disable every extension having
bugs? That sounds weird, besides that only the RMs has the last word
on that.
No, I said I'm going to disable new extension that is known to
cause obscure problems in the past and that still does cause them at present,
and that was (mistakenly) enabled by default right after its creation.
And I feel it's now or never, since after alpha2 we'll hear "oh, it's too
late to disable it, users now expect it to be enabled".
At least that's quite expected after seeing "we enabled it just for alpha"
(ha-ha! why don't you enable everything in alpha releases then?).
--
Wbr,
Antony Dovgal
Hi Tony,
No, I said I'm going to disable new extension that is known to cause
obscure problems in the past and that still does cause them at present,
and that was (mistakenly) enabled by default right after its creation.
That really wasn't an obscure bug once the user posted the dump.
Re-assigning it as a Phar bug would've meant it got fixed at the point Greg
asked 'are there any open Phar bugs?', if not before...!
- Steph
Hi Tony,
No, I said I'm going to disable new extension that is known to cause
obscure problems in the past and that still does cause them at present,
and that was (mistakenly) enabled by default right after its creation.That really wasn't an obscure bug once the user posted the dump.
Re-assigning it as a Phar bug would've meant it got fixed at the point Greg
asked 'are there any open Phar bugs?', if not before...!
Not sure what you meant here, but I've been informed about it about 1 hour ago.
Surely asking "how many bugs are left" is quite useless, there is bug DB search,
there should be some test facilities.
See, I personally keep my extensions in alpha-beta status for quite a long time just to
make sure they're mature enough to be called "stable".
At this moment I don't see any reasons to call ext/phar "stable", therefore it should
not be enabled by default. Especially taking into account its complexity and the fact
that it "intercepts" core functions, which potentially may break everything, not just
phar_*() functions.
This is not an attack on ext/phar as somebody might have thought, I just don't want
to see yet another release fail.
--
Wbr,
Antony Dovgal
Hello Antony,
Tuesday, August 12, 2008, 5:27:54 PM, you wrote:
Hi Tony,
No, I said I'm going to disable new extension that is known to cause
obscure problems in the past and that still does cause them at present,
and that was (mistakenly) enabled by default right after its creation.That really wasn't an obscure bug once the user posted the dump.
Re-assigning it as a Phar bug would've meant it got fixed at the point Greg
asked 'are there any open Phar bugs?', if not before...!
Not sure what you meant here, but I've been informed about it about 1 hour ago.
Surely asking "how many bugs are left" is quite useless, there is bug DB search,
there should be some test facilities.
See, I personally keep my extensions in alpha-beta status for quite a long time just to
make sure they're mature enough to be called "stable".
At this moment I don't see any reasons to call ext/phar "stable", therefore it should
not be enabled by default. Especially taking into account its complexity and the fact
that it "intercepts" core functions, which potentially may break everything, not just
phar_*() functions.
This is not an attack on ext/phar as somebody might have thought, I just don't want
to see yet another release fail.
As much sense as that makes. Phar was pretty stable and had it users. Now
for 5.3 we added a ton of new features. It is only naturally that we still
might have small issues, maybe even a few that cause real problems. But as
said, we'll be fixing them hopefully prior to the release.
Best regards,
Marcus
Hi Tony,
Not sure what you meant here, but I've been informed about it about 1 hour
ago.
Sorry - it was assigned to you, so I assumed you were aware it was actually
a Phar bug. My bad, I didn't reflect on just how many bugs are assigned to
you.
Surely asking "how many bugs are left" is quite useless, there is bug DB
search, there should be some test facilities.
Greg at that point had limited inet access, hence the question. I did a bug
DB search... but that particular bug showed up as Apache2, ie it never came
up in my search results. In fact there were no open Phar bugs.
See, I personally keep my extensions in alpha-beta status for quite a long
time just to make sure they're mature enough to be called "stable".
We've had two alphas and a beta release between March and now, and another
beta release is planned in PECL shortly. (In fact I had hoped it would be
this week, since Greg's now able to communicate again.) I think 5 months is
a reasonable length of time for an extension to be in alpha-beta,
personally.
At this moment I don't see any reasons to call ext/phar "stable",
therefore it should not be enabled by default.
PHP_5_3 is also not called "stable" at this point. It'd be a different
matter if it were.
Especially taking into account its complexity and the fact
that it "intercepts" core functions, which potentially may break
everything, not just phar_*() functions.
Dmitry altered the logic in function interception a few weeks ago, which is
precisely why it needs thorough testing now.
This is not an attack on ext/phar as somebody might have thought, I just
don't want to see yet another release fail.
Understood. But, I don't think any of us want to see that.
- Steph
Sorry - it was assigned to you, so I assumed you were aware it was actually
a Phar bug. My bad, I didn't reflect on just how many bugs are assigned to
you.
I assigned it to me in order to keep track of it.
We've had two alphas and a beta release between March and now, and another
beta release is planned in PECL shortly. (In fact I had hoped it would be
this week, since Greg's now able to communicate again.) I think 5 months is
a reasonable length of time for an extension to be in alpha-beta,
personally.
You can't call it alpha, continue active development for two months and then
call it stable, that's pointless.
The diff since March is more than 1Mb, it's a different extension already.
At this moment I don't see any reasons to call ext/phar "stable",
therefore it should not be enabled by default.PHP_5_3 is also not called "stable" at this point. It'd be a different
matter if it were.
Correct.
But they don't install it by default on all computers.
--
Wbr,
Antony Dovgal
I assigned it to me in order to keep track of it.
Ack, it's not a problem, I'm very glad someone's doing that. Just this
time it meant there was an open Phar bug that none of the Phar team knew
existed for the last few weeks.
We've had two alphas and a beta release between March and now, and
another beta release is planned in PECL shortly. (In fact I had hoped it
would be this week, since Greg's now able to communicate again.) I think
5 months is a reasonable length of time for an extension to be in
alpha-beta, personally.You can't call it alpha, continue active development for two months and
then call it stable, that's pointless.
The first beta release was in May. There's been no active development since
Dmitry's 'Phar week', and aside from that there's been no active development
since June.
The diff since March is more than 1Mb, it's a different extension already.
Try a diff since the last beta release. I think you'll find most of it's
either whitespace or tests - the remainder shouldn't add up to much.
At this moment I don't see any reasons to call ext/phar "stable",
therefore it should not be enabled by default.PHP_5_3 is also not called "stable" at this point. It'd be a different
matter if it were.Correct.
But they don't install it by default on all computers.
Exactly :) so there's no problem in having an extension in beta alongside
it.
- Steph
Hello Antony,
Tuesday, August 12, 2008, 4:25:37 PM, you wrote:
I can agree that disabling something that was already enabled in 5.2 might create
some confusion, but why enable scarcely created extensions by default, especially if
they are known to cause lost of obscure problems in the past (like Phar)?
See http://bugs.php.net/bug.php?id=45613 for example.
Who would have thought that there are multithreaded web-servers, eh?
I'm going to disable ext/phar before alpha2.
You've been warned.
Fixed :-)
Best regards,
Marcus
See http://bugs.php.net/bug.php?id=45613 for example.
Who would have thought that there are multithreaded web-servers, eh?I'm going to disable ext/phar before alpha2.
You've been warned.Fixed :-)
I'm sorry to say that, but the problem is far more deeper than you thought.
No, it still segfaults.
--
Wbr,
Antony Dovgal
Hello Antony,
Tuesday, August 12, 2008, 5:05:08 PM, you wrote:
See http://bugs.php.net/bug.php?id=45613 for example.
Who would have thought that there are multithreaded web-servers, eh?I'm going to disable ext/phar before alpha2.
You've been warned.Fixed :-)
I'm sorry to say that, but the problem is far more deeper than you thought.
No, it still segfaults.
Well in that case I'd need more stack traces to fix more and obviously the
reaosn to have an alpha and beta phase is for instance getting these fixed.
If you still insist on disabling it, you should at least wait till we are
closer to release so that we get the chance to fix more of these.
Best regards,
Marcus
If you still insist on disabling it, you should at least wait till we are
closer to release so that we get the chance to fix more of these.
Are you saying we need to enable by default all extensions in order to fix their bugs?
I don't recall seeing such practice before.
--
Wbr,
Antony Dovgal
If you still insist on disabling it, you should at least wait till
we are
closer to release so that we get the chance to fix more of these.Are you saying we need to enable by default all extensions in order
to fix their bugs?
I don't recall seeing such practice before.
Tony, you have made your point. Please give the developers in question
as well as RM's the benefit of the doubt here. The these extensions
have been enabled because that is what the bulk of the core developers
seemed to have agreed upon.
If we, the RMs, see that these extensions are not yet ready, we will
not hesitate to pull any of them. We will make such a decision before
we go into the RC phase. Until then it would be only fair to not push
the developers in question into such a defensive corner. They should
spend their open source brain cycles on fixing bugs not in this thread.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
If we, the RMs, see that these extensions are not yet ready, we will
not hesitate to pull any of them. We will make such a decision before
we go into the RC phase. Until then it would be only fair to not push
the developers in question into such a defensive corner. They should
spend their open source brain cycles on fixing bugs not in this thread.
The point is that I don't see any results of this thread.
Or rather the results are quite indefinite.
Some say these extensions are soooo vital, that should be kept enabled
forever, others are in doubt. Some say that they are enabled for alpha only,
others say this is not yet final.
But the fact is - they are enabled and that concerns me because
I do not believe it's going to change at all.
--
Wbr,
Antony Dovgal
If we, the RMs, see that these extensions are not yet ready, we
will not hesitate to pull any of them. We will make such a
decision before we go into the RC phase. Until then it would be
only fair to not push the developers in question into such a
defensive corner. They should spend their open source brain cycles
on fixing bugs not in this thread.The point is that I don't see any results of this thread. Or rather
the results are quite indefinite.
What result are you expecting?
That they are removed immediately?
That all bugs are instantly fixed?
That the previous decisions of enabling by default of these extensions
is revoked in light of bugs being found in the alpha phase of 5.3?
This would be unreasonable.
What is reasonable is that it has been acknowledged that several of
the newly added and enabled by default extensions have issues. And the
reassurance that if these bugs do not get resolved these extensions
might not be enabled by default or not even bundled to begin with.
Nobody is saying "Tony do not mention issues in new extensions". But
pointing to bugs in code that is part of alpha releases (or to make it
even clearer non RC/stable releases) and saying this is enough to
revert previous decisions is not fair to the developer (and the users
waiting for these features).
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
What result are you expecting?
That they are removed immediately?
That all bugs are instantly fixed?
That the previous decisions of enabling by default of these extensions
is revoked in light of bugs being found in the alpha phase of 5.3?
No, I didn't expect them to be removed immediately.
But what I see now is strong objection against their removal even though
there are clear arguments for it.
Therefor, I'd expect some kind of plan like "wait for X weeks or till X alpha,
then check the number of bugs fixed. If it's still too high -> the extensions
are apparently not ready.", or "wait till alphaX, then start voting", or "wait
till aplhaX and I'll tell you my decision".
revert previous decisions is not fair to the developer (and the users
waiting for these features).
sigh
That's exactly why I don't think it's going to change whatever I do.
"Users waiting for features" will surely beat any common sense.
--
Wbr,
Antony Dovgal
Therefor, I'd expect some kind of plan like "wait for X weeks or
till X alpha, then check the number of bugs fixed. If it's still too
high -> the extensions are apparently not ready.", or "wait till
alphaX, then start voting", or "wait till aplhaX and I'll tell you
my decision".
I gave you a plan. We will decide before going to RC. Depending on how
things go we might even act earlier.
For example fileinfo really needs work and if nothing happens before
alpha2, I can see it being dropped for 5.3 entirely. That being said I
hope that this will not be necessary.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
Hello Antony,
Tuesday, August 12, 2008, 5:31:08 PM, you wrote:
If you still insist on disabling it, you should at least wait till we are
closer to release so that we get the chance to fix more of these.
Are you saying we need to enable by default all extensions in order to fix their bugs?
I don't recall seeing such practice before.
That would actually be a good thing to do. But seriously we decided to give
Phar a try, so we should stick to that until close to final release.
Best regards,
Marcus
That would actually be a good thing to do. But seriously we decided to give
Phar a try, so we should stick to that until close to final release.
See, that's exactly what I said to Pierre ten minutes ago.
We'll keep it enabled until close to the release, but we won't
disable it EVER "because it was enabled all the way long and now it's too late"
or "it looks stable enough for me".
--
Wbr,
Antony Dovgal
Antony Dovgal wrote:
I can agree that disabling something that was already enabled in 5.2
might create some confusion, but why enable scarcely created
extensions by default, especially if they are known to cause lost of
obscure problems in the past (like Phar)?See http://bugs.php.net/bug.php?id=45613 for example.
Who would have thought that there are multithreaded web-servers, eh?I'm going to disable ext/phar before alpha2.
You've been warned.
Hi,
I've just returned home finally, and look forward to taking a look at
issues. I even committed 2 new code coverage tests while on the road,
in case you doubt my resolve to fix things up.
Tony, please drop the posturing, it makes you look somewhat ridiculous
:). I explicitly asked that the question of enabling phar by default
be voted on prior to rc 1 when I enabled it, and again reminded about it
a month later. Please see the links below to the emails in question.
Let's not forget - disabling ext/phar by default involves changing a 1
to a 0 in config.m4, it's hardly difficult to do. I agree that it needs
to happen prior to the final release cycle or not at all. Is alpha2 the
new rc1? That makes no sense to me if so.
Thanks,
Greg
From May 14, 2008: http://marc.info/?l=php-internals&m=121078127525090&w=2
From June 23, 2008: http://marc.info/?l=php-internals&m=121419199122615&w=2