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
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 apl
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 di
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, a
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 M
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 fai
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
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 qui
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 release
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 in
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 defa
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
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 su
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 bug
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.
>>> Y
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-ass
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 mor
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 havin
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
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
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 http://
On 01.08.2008, at 12:30, 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
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
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 then
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 - PHP
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
--
David Zülke wrote:
Which reminds me I was meaning to ask... Why is ext/xsl not enabled by
default?
Because of its dependency on libxslt.
--
Sebastian Bergmann http://sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69
--
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
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 fo
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
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 to
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 bu
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 and
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 Develo
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 exten
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 configur
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)? Wh
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
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 exte
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:
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
tok
41 matches
Mail list logo
