Hi Steph, On Tue, Apr 1, 2008 at 4:18 PM, Steph Fox <[EMAIL PROTECTED]> wrote: > Hi Pierre, > > > > and about Attic, the idea behind a graveyard was about leaving the > > code around for study purposes. > > Code in the attic can be read online but can't be checked out, so I take > your point about 'study purposes'. I'd use siberia for things like axis2, > where the project is live and hosted elsewhere but the original code is > still in PECL. Or classkit, which was superceded by runkit but which still > works.
All of them belong to siberia, just like the gpl'ed dead cows. KISS. > Marcus' demoext could go into siberia too - it's literally just a > demo and may be useful to some, but it shouldn't really be part of a PECL > checkout. I strongly disagree, the demoext must remain in PECL and can even have releases. The main goal (and to be honest, fantastic goal) is to teach how to write a PHP extension. How can we relegate it to siberia? > >> I'd call the 'PECL versioning' one a done deal at this stage, pretty > >> much - > >> it just needs a write-up on pecl.php.net for newcomers to refer to, and > >> a > >> request for the final handful of extensions to comply. > > > > Filling a bug may be enough. > > Nah, I'll do the polite thing and send out emails today. We can file bugs > when people don't comply _after_ the request (and after we have something > with clear rules we can link to!). There is nothing not polite to report bugs. It is even the first form of OS contribution. > >> We probably need a whole new RFC for core module versioning. Want to > >> kick it > >> off? > > > > I would not like to have different docs explaining the same thing It > > will be very confusing. We already covered almost every problem for > > core or pecl extensions. > > I thought that at first too, but Christopher Jones faced me off-list with > some scenarios I hadn't considered. It's more complex than we'd allowed > because a single PECL extension can be symlinked to more than one PHP > branch - we need to look into this more. Indeed, we discussed these cases too and I pointed your attention many times to the complexity of this situation. That does not change my thoughts: one goal (covering many cases), one RFC, one doc. > > > Let make it clean and readable and then see > > how it can be improved. > > OK, but I need to spend some time on 'real work', so can I leave this with > you for now? What I like in communication based on mails is that they are asynchronous (or should be ;) Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
