Hi, On Wed, Jul 2, 2008 at 10:00 PM, Lukas Kahwe Smith <[EMAIL PROTECTED]> wrote: > Aloha, > > Since Johannes has been stumped (and therefore not as visible as he would > have hoped) with work and 5.3 CVS is already filled brim with awesome new > features, I have been approached by several people wondering how we can > speed up the process. I have always said I am available to play the > secretary to the RM, but in order to ensure that developers have a greater > chance of having an RM to talk to, Johannes agreed to move me to co-RM > status. > > I hope we do not have to have a fundamental discussion about the merits of 2 > RMs. Having 2 RMs should hopefully help speed up the 5.3 release cycle. Of > course it will be the job of the two RMs to ensure that we are sufficiently > in sync with each other. But I guess we are hopeful that adding an RM is not > made unfeasible by this additional communication between the RMs. > > Anyways, I have updated the 5.3 todo page [1] with all the todo items I have > seen flying over the list and IRC. Other people have also added their todo > items after my recent request [2]. The purpose of the todo list in the > current stage is to show what people are working on and are hoping to get > into 5.3. It is now the job of the RMs to figure out if indeed we can align > all of these features towards a sensible date for 5.3. Also we need to > figure out if the items are still of relevance and if the names behind the > items are valid and when the relevant developers expect to be able to > finish. > > Given all of this we see several items on the list as the key features of > this release: > 1) namespaces > Here we need to make sure that the current state is now in a coherent state. > I think Derick still has some issues [3] with the recent change by Greg [4], > but even his criticism did not sound all to loud. So I think we are in a > good state here?
I'd really like to see a decision on naming for internal namespaces before the feature is out. So we can document it and not worry about BC when we will actually use it. > > 2) late static binding > Etienne had some questions recently [5], which were met by criticism by Stas > [6]. However all others agreed with the change. So I guess we are solid here > too? Yes, the only thing remaining is a tad of love from somebody with ZE karma to commit the patches. > > 3) re2c > Rui recently came to the list with notes on the ZE MB feature [7]. > > @Scott/Marcus: Is this enough for you guys to get this working? > @Rui: Is there any chance you can get more people in the japanese (or asian > in general) community involved here? > > 4) windows support > Ever since Edin disappeared it has become clear that we have a bus factor > issue with windows support. The windows team is working to rectify this > situation. We need to make sure that the infrastructure to deliver windows > binaries for PHP 5.3 as well as PECL extension is in place before we can > release 5.3. > > @Elizabeth/Pierre/Rob: How are things on this front? > > 5) BC issues > Well this is a bit of an "anti-feature" in the sense its not a task anyone > is dedicated to. The point is that we need to make sure that we understand > any BC issues we currently have, so that we can either correct them or > document them. > > @Philipp: Since you are the god of documentation .. How are things looking > on the scratchpad [8] you started? > > These are the 5 areas we the RMs would hope that people focus on. Thats > actually 3 focus areas too many for my taste, but goes to show that we might > want to release more often (given that the list for 5.4 is already cramming > up [9]). > > On top of this we also have a few other changes that are of quite some > importance, but that to me will not stop a release if they do not make it > (for the extensions we feel that they will be available via PECL for those > who really need them now in the worst case). But these are big features non > the less that could warrant a new minor release on their own alone if it > would be for even bigger stuff: > 1) intl extension > Last discussion ended without a decision on the class naming [10]. I > specifically remember Derick taking issue with intl ext "invading" the date > ext namespace. Stas however arguing that the intl ext is supposed to bring > some forwards compatibility to PHP 6 and therefore naturally will need to > span the namespaces of other extensions, that are planned to be expanded for > PHP 6. > > 2) phar extension > I guess we are pretty solid here? > > 3) E_DEPRECATED > Here we just need to make sure that we actually mark only the things as > deprecated that we actually want to deprecate [11]. This ties in a bit with > the BC issues point above. > > 4) __callStatic > > 5) Garbage Collection > > So is anything missing? Please everybody take time to review the todo list, > make sure that all items are on the list, make sure that the information is > as up to date as possible. Finally anyone who's name is on this list (or who > will add himself) should get in contact with Johannes and myself within 1 > week (thats July 9th) to explain the state of the todo item and when he can > finish the item and what the general impact the feature has on the release. > Also please bring up any issues, especially for the above 6 points, to the > list and try to focus on solving the issues in a timely manner. We RMs will > try to moderate as much as possible, but understand that at some point we > will have to have to go with one approach (or in the worst case we might > have to push a feature to 5.4). > > After July 9th, we will then publish a tentative release plan within 3 days > afterwards. Again ideally people will be available for short feedback loops > during this period. If you are unable to follow internals@ during this > period, please make sure we have some way to contact you (email, IM, phone > whatever). If you are not available please also just let us know. Its not > about forcing developers to call the RMs if they want to go out to the > movies. It just makes our work a bit easier, but in the end its about > finding the right balance in timing, features and stability, so as this is > PHP so common sense always rules any dates (or the nerves of the RMs). > > The tentative schedule will probably try to move us quickly towards a > feature freeze together with a first alpha. Depending on our discoveries we > will schedule beta and RC releases (obviously subject to continued review). > > Summary: > Everybody review [1] and make sure all items you care about are on the list > and your name only appears next to stuff you are actually able to complete > in a timely manner. > > regards, > Lukas and Johannes > > [1] http://wiki.php.net/todo/php53 > [2] http://marc.info/?l=php-internals&m=121438504121772&w=2 > [3] http://marc.info/?l=php-internals&m=121446594113602&w=2 > [4] http://marc.info/?l=php-internals&m=121397701404954&w=2 > [5] http://marc.info/?l=php-internals&m=121397858807587&w=2 > [6] http://marc.info/?l=php-internals&m=121400956517854&w=2 > [7] http://marc.info/?l=php-internals&m=121474666513126&w=2 > [8] http://wiki.php.net/doc/scratchpad > [9] http://wiki.php.net/todo/php53#future_php_releases > [10] http://marc.info/?l=php-internals&m=120719875404217&w=2 > [11] http://marc.info/?l=php-internals&m=121390431523970&w=2 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > > -- Etienne Kneuss http://www.colder.ch Men never do evil so completely and cheerfully as when they do it from a religious conviction. -- Pascal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
