Re: [PHP-DEV] Re: 5.3 Release Planning
On 07.03.2008 18:15, Gregory Beaver wrote: > I wholeheartedly agree that phar needs more testing. I also think some > other areas of php could have used more testing Undoubtedly. >> And I'm still not convinced we should include any PECL extensions in the >> core, >> I believe it should go the other way round. > > This is secondary, but I'm proposing using phar to test the mechanism > that will allow ext/ to migrate to pecl/ and still work as it did in ext/ Ok, here I guess I should and read that thread Steph mentioned.. -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 5.3 Release Planning
Antony Dovgal wrote: > On 07.03.2008 05:43, Gregory Beaver wrote: >> Just a quick note: I'd like to consider another possible approach, >> having pecl/phar synced from stable pecl release. > > I'm not sure it's good idea. > IMO it should go trough much more thorough testing to be included into the > core. Hi, I wholeheartedly agree that phar needs more testing. I also think some other areas of php could have used more testing, such as the serious issues I found in zlib stream filters, but they were useful for years even with edge case flaws. Areas that I know phar needs work: * big-endian like PPC tar/zip support is incomplete, I need to write the simple byte order reversal that will complete this, and add the same compiler flags to the tar struct that we use on zip structs. This is an easy fix. * finishing up include_path support for streams. Other threads address this issue. This will remove the need for most of the proposed magic in pecl/phar/TODO. * ensuring full code coverage of tests, we're currently at about 68-70% * finishing up Steph's work on data-only tar/zip support (non-executable tar/zip read/write) * 2 open bugs at pecl.php.net * more hammering should be done on the web front controller to ensure edge cases have been considered Areas of phar that are rock-solid: * phar stream read/write * file format support for the 3 file formats read/write * anything else not yet mentioned. I expect to be able to wrap up the issues listed very quickly. Tony has been fantastic at finding memleaks/segfaults as new features are added, and we welcome the minutest scrutiny. > And I'm still not convinced we should include any PECL extensions in the core, > I believe it should go the other way round. This is secondary, but I'm proposing using phar to test the mechanism that will allow ext/ to migrate to pecl/ and still work as it did in ext/ Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 5.3 Release Planning
The very same could be said about phar. It's going through a final wave of intensive development that *adds* to existing features; the core functionality's solid, and has been for some time. Given the end of April 'freeze', we're at least 2 months away from a 5.3 release. Assuming Greg's include patch or something akin to it is accepted into 5.3, all of that is fine-tuning time. What Greg's suggesting is that if phar goes into the distro, it can act as an early live test subject. - Steph -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 5.3 Release Planning
On 07.03.2008 16:09, Steph Fox wrote: > Hi Tony, > >> Well, lets make it convenient then. >> Including everything into the core is not a solution. > > You seem to have missed an entire thread on the subject, along with the > conclusion that the mechanisms for really doing a good job on this can't > sanely be in place before 5.3.0 is released. They will need thorough testing > before we start moving stuff out of core, and there just isn't time for > that. It's more likely to be 5.4 before we can call it 'reliable'. The very same could be said about phar. > What Greg's suggesting is that if phar goes into the distro, it can act as > an early live test subject. -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 5.3 Release Planning
Hi Tony, Well, lets make it convenient then. Including everything into the core is not a solution. You seem to have missed an entire thread on the subject, along with the conclusion that the mechanisms for really doing a good job on this can't sanely be in place before 5.3.0 is released. They will need thorough testing before we start moving stuff out of core, and there just isn't time for that. It's more likely to be 5.4 before we can call it 'reliable'. What Greg's suggesting is that if phar goes into the distro, it can act as an early live test subject. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 5.3 Release Planning
On 07.03.2008 12:32, Alexey Zakhlestin wrote: >> I'm not sure it's good idea. >> IMO it should go trough much more thorough testing to be included into the >> core. >> >> And I'm still not convinced we should include any PECL extensions in the >> core, >> I believe it should go the other way round. > > it would be better to say not "in core", but "in official distribution" PECL is officially distributed either. What I mean by the "core" is ext/ subdirectory of the sources tarball. > until there is convenient cross-platform of installing extensions from > pecl, important ones should be included in distribution Well, lets make it convenient then. Including everything into the core is not a solution. -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 5.3 Release Planning
On 3/7/08, Antony Dovgal <[EMAIL PROTECTED]> wrote: > On 07.03.2008 05:43, Gregory Beaver wrote: > > Just a quick note: I'd like to consider another possible approach, > > having pecl/phar synced from stable pecl release. > > > I'm not sure it's good idea. > IMO it should go trough much more thorough testing to be included into the > core. > > And I'm still not convinced we should include any PECL extensions in the > core, > I believe it should go the other way round. it would be better to say not "in core", but "in official distribution" until there is convenient cross-platform of installing extensions from pecl, important ones should be included in distribution -- Alexey Zakhlestin http://blog.milkfarmsoft.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 5.3 Release Planning
On 07.03.2008 05:43, Gregory Beaver wrote: > Just a quick note: I'd like to consider another possible approach, > having pecl/phar synced from stable pecl release. I'm not sure it's good idea. IMO it should go trough much more thorough testing to be included into the core. And I'm still not convinced we should include any PECL extensions in the core, I believe it should go the other way round. -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: 5.3 Release Planning
Hi, On Thu, 2008-03-06 at 20:43 -0600, Gregory Beaver wrote: > Just a quick note: I'd like to consider another possible approach, > having pecl/phar synced from stable pecl release. Yes, that's what I'd like, too. Te problem there is that developers using CVS checkouts should get a CVS checkout f it, too so it's being tested and can be fixed if needed. And if you read my mail you see that I mentioned doing it during buildconf, which is better than configure, I think ;-) > I am also fine with symlinking until this can be perfected, as it is > just an idea to be implemented right now. right. /me has no powers for actually doing that. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: 5.3 Release Planning
Johannes Schlüter wrote: > Hi all, > > recently there were quite a few proposals about stuff for 5.3. If we > implement > them all we won't finish in a "soonish" time and we get new ideas postponing > the 5.3 release therefore the following: > > - Scanner based on re2c: > Going to re2c promises to make maintenance simpler and increase the parsers > performance. Currently the prototype does not provide support for Zend > multibyte mode. This seems doable within April. Hence I ask for finishing > by end of April the latest. Once that is done we will go over to a freeze > and > switch to bug fixing only mode. > If this is done sooner than we'll freeze sooner, too. If there are delays > we'll freeze anyways and use the scanner for a later release. > > - bundling pecl/intl > According to Stas it's ready for being bundled and was voted in. The only > question I see there is the "how to bundle it". There we should definitely > find a better thing than symlinking around on the CVS server, an option > might be to to switch to subversion and use svn:externals or keeping stuff > in pecl and then having some scripts (maybe part of buildconf/the release > scripts) fetching them into a checkout. Just ideas ... For the moment > symlinking might be the best. > > - bundling pecl/phar > Lots of work has been done there, I'd like to have it in, general PECL > discussion: See above. Hi, Just a quick note: I'd like to consider another possible approach, having pecl/phar synced from stable pecl release. I think this can be done via a simple configure script that wgets the latest stable and uses a clever little PHP_Archive-based phar to extract the source files. There are of course other ways to do this that may be better than my quick-and-dirty description, but it is certainly possible. As the primary maintainer of the PEAR installer, this would make it easier for me to fix issues found in this process. Because phar is new, this will give more wiggle room for experimenting, and what we figure out could then be used to allow the current vaporware proposal of moving all exts to pecl. I am also fine with symlinking until this can be perfected, as it is just an idea to be implemented right now. phar is in a state of slight flux: if stream wrappers get supported inside include_path, it would change a lot of the implementation stuff I've needed to do, and greatly simplify phar, so it will continue to improve with this addition. Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
