Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:47234
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain pooteeweet.org from 188.40.37.16 cause and error)
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <alpine.DEB.2.00.1003131123540.4153@kossu.derickrethans.nl>
Date: Sat, 13 Mar 2010 18:45:29 +0100
Cc: Rasmus Lerdorf <rasmus@lerdorf.com>,
 PHP Developers Mailing List <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <C64FA94D-18E3-4148-9583-8AE46392CA6C@pooteeweet.org>
References: <4B9926E8.4080202@lerdorf.com> <alpine.DEB.2.00.1003131123540.4153@kossu.derickrethans.nl>
To: Derick Rethans <derick@php.net>,
 David Soria Parra <dsp@php.net>,
 Philip Olson <philip@php.net>
Subject: Re: [PHP-DEV] PHP 6
From: mls@pooteeweet.org (Lukas Kahwe Smith)


On 13.03.2010, at 17:57, Derick Rethans wrote:

> I do however think that most of the current approaches of adding =
Unicode=20
> support into PHP 6 (current trunk) have the proper ideas behind that,=20=

> but I do think that in some cases we went slightly overboard of=20
> supporting Unicode everywhere with the new "unicode" type. For =
example,=20
> we don't really need to have this for variable or function names or=20
> support every encoding for writing scripts in. (We do=20
> need to *support* Unicode there, but not with the unicode string =
type.)=20
> Another example is that we perhaps don't have to support every =
encoding=20
> out there.

Right, dropping the current trunk doesnt mean that we should forget =
about unicode. However we need to find a balance between ease of use, =
performance (especially for those who do not need better unicode =
support) and release timeframe.

> So I would suggest the following things to do:
>=20
> - get rid of Jani's play branch
> - move trunk to branches/FIRST_UNICODE_IDEA
> - put 5.2 in security fix only mode
> - pht 5.3 in bug fix only mode
> - start adding new features (traits, Ilia's scalar typehint patch,=20
>  output buffering things) to the new trunk cloned from 5.3.

+1

As for the exact features to merge, lets first start with formulating a =
plan about what we want to see in the next release. I also think it =
makes sense to base the number and scope if the features on a rough idea =
of when we want to see this next release. In order to put together that =
release plan i guess we should have an RM defined first. I think Andi =
said the same thing on IRC yesterday.

I can certainly see you as RM, but i would like to propose another newer =
guy for the job:
David Soria Parra

That being said, I also think that the model of a co-RM that focuses on =
the less technical aspects as proven itself with 5.3. not only does it =
mean the work load is spread over two shoulders, it also means that =
developers can get answers quicker (especially as we are all sometimes =
swamped with work or god forbid go on vacation). I am willing to take =
the co-RM role again. I can also see Philip in this role. But I think =
the more important question is to find the technical RM and if the =
technical RM feels like he can use the support he can just appoint a =
co-RM.

regards,
Lukas Kahwe Smith
mls@pooteeweet.org