On 01.08.2008 14:11, 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
hi,
On Tue, Aug 12, 2008 at 4:25 PM, Antony Dovgal [EMAIL PROTECTED] wrote:
On 01.08.2008 14:11, 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
Hello Antony,
Tuesday, August 12, 2008, 4:25:37 PM, you wrote:
On 01.08.2008 14:11, 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
On 12.08.2008 18:50, Pierre Joye 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.
Are you saying that you are going to disable every extension
On 12.08.2008 18:59, Marcus Boerger 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
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.
Hello Antony,
Tuesday, August 12, 2008, 5:05:08 PM, you wrote:
On 12.08.2008 18:59, Marcus Boerger 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
On 12.08.2008 19:12, Steph Fox 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
On 12.08.2008 19:23, Marcus Boerger 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
Hello Antony,
Tuesday, August 12, 2008, 5:27:54 PM, you wrote:
On 12.08.2008 19:12, Steph Fox 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
Hello Antony,
Tuesday, August 12, 2008, 5:31:08 PM, you wrote:
On 12.08.2008 19:23, Marcus Boerger 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
On 12.08.2008, at 17:31, Antony Dovgal wrote:
On 12.08.2008 19:23, Marcus Boerger 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
On 12.08.2008 19:36, Marcus Boerger wrote:
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
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
On 12.08.2008 19:35, Lukas Kahwe Smith wrote:
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
On 12.08.2008, at 17:54, Antony Dovgal wrote:
On 12.08.2008 19:35, Lukas Kahwe Smith wrote:
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
On 12.08.2008 19:49, Steph Fox wrote:
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
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,
On 12.08.2008 20:02, Lukas Kahwe Smith wrote:
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
On 12.08.2008, at 18:19, Antony Dovgal wrote:
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
Antony Dovgal wrote:
On 01.08.2008 14:11, 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
On Fri, 2008-08-01 at 14:11 +0400, Antony Dovgal wrote:
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
Perhaps its more of a perception then anything else. If enabled by
default simply meant we do so because we can (no external libs needed)
rather we think you should have it. There really would be any sort of
an issue, and perhaps finally convince people to install what they
need rather
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
xmlwriter
On 01.08.2008 18:34, Chris Stockton wrote:
Is their a particular reason you are against giving users such a variety of
tools?
I'm against enabling untested and unmaintained extensions by default,
especially if they are known to cause problems.
--
Wbr,
Antony Dovgal
--
PHP Internals -
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
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
On 01.08.2008 14:20, Scott MacVicar 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
Antony Dovgal wrote:
On 01.08.2008 14:20, Scott MacVicar 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
On 01.08.2008 14:41, Scott MacVicar wrote:
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
Hi folks,
Am 01.08.2008 um 12:30 schrieb Antony Dovgal:
On 01.08.2008 14:20, Scott MacVicar 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)?
On Fri, Aug 1, 2008 at 12:43 PM, Antony Dovgal [EMAIL PROTECTED] wrote:
On 01.08.2008 14:41, Scott MacVicar wrote:
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
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
On 01.08.2008 14:55, Pierre Joye wrote:
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
--
PHP Internals - PHP Runtime
On 01.08.2008 15:44, Pierre Joye wrote:
It is not about being 100% true or 100% false. We have a couple of
ways to see that, extension usage stastistics and own experiences
(mines in the PEAR time, with htscanner feedbacks on what they use,
and a couple of other things). I provided one source
The more extensions enabled by default, the more extensions many developers
can count on being in common builds. Part of PHP's success is the extension
system and the variety of tools it gives the user-base. It is also a nice
peace of mind for library developers to be fairly sure the typical php
Hello Robert,
Friday, August 1, 2008, 12:44:20 PM, you wrote:
Hi folks,
Am 01.08.2008 um 12:30 schrieb Antony Dovgal:
On 01.08.2008 14:20, Scott MacVicar 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
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
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
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
40 matches
Mail list logo
