Hello LAUPRETRE,

  to cut this short. Noone tried to overrule anyone and noone tried to
outsmart or trick in any sense either. In the past we decided on the
following. First it is to early to ring in Phar for a variety of reasons. As
development went on it was more than appropriate for the RM to ask whether
this might have related in a change of opinions.

And btw, basically you are doing the same thing here, by mentioning PHK
again and again you do not get any benefit either :-) Instead you need to
put PHK into PECL and follow all rules before being able to oppose Phar with
PHK.

marcus

Wednesday, September 12, 2007, 2:07:28 PM, you wrote:

>> From: Stanislav Malyshev [mailto:[EMAIL PROTECTED] 
>>
>> > 14) Link phar extension from PECL into core (possibly enabling it by
>> > default)
>> 
>> -1, we discussed why :) 0 if not enabled by default.

> Yes, it was discussed, and I thought it was clear for everybody that phar had 
> to remain
> in pecl and was not mature enough for core.

> Once again, as we don't have any formal RFC/decision process, people whose 
> proposal was
> clearly rejected/delayed can still have it approved: they just have to wait a 
> little
> and, then, hide it in the middle of a bunch of more important votes. Once 
> your software
> is in the core, it is easy: if somebody wants to remove it, you invoke BC 
> breaks !

> That's exactly what is done here. As most people forgot the discussion about 
> PHAR vs
> PHK, it is proposed again, but today it is hidden into a lot of more 
> problematic
> decisions, like register_globals and safe_mode, which will generate a lot of 
> buzz and
> help keep it hidden.

> I proposed several times to implement a more formal RFC process for PHP but 
> didn't get
> much success. As the Zend Framework has implemented such a tool, what would 
> you think
> of a similar site for the PHP core ?

> Francois




Best regards,
 Marcus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to