I see no point to discuss solutions for some unknown entities willing to contribute when they do not consider to introduce themselves. When they don't explain clearly why we should do the move and what will be the actual gains for us (read: for "us" not for them). Until a step in this/our direction is not done, I will not see a point to think about solutions as it means they don't really care about us but Zend and associates (as they seem to communicate only with them as far as I understand).
Pierre has a point here. So far we've heard from: Wez, Andi and Jay. (We've also heard from Dan, Adam and David, but none of them have declared an interest.)
On the other hand - Pierre, it's now clear that there have been ongoing discussions for some time, and that Andi, Jay and Wez have been involved in those discussions. Between them, they have made it fairly clear that enforcing some kind of restriction is the only way to have the various teams work together at all. I would imagine this doesn't affect MySQL, PostgreSQL or SQLite directly, but if we're talking about various experts getting together to determine a common approach then preventing the key folk from IBM/Microsoft/Oracle/whatever from doing so will mean the approach can't be synced, e.g. the Oracle guys won't be able to talk with the SQLite guy about their inner database needs etc etc.
I'm working on the principle that it will be good for PHP to enable those teams to work together. I'm hopeful that this won't touch the PHP core at all, because if it does we simply have to say 'no', end of story. I'm also hopeful that PDO itself (if none of its drivers) will be considered part of the PHP core. If the teams concerned can manage on that basis, I'd count that as a victory - I'm not interested in seeing PDO itself subjected to a CLA. Product-specific drivers are a different matter.
Now, PECL has a couple of CLA'd modules already. I don't like them being there, and you have stated your own opinion loud and clear. I think we should be looking for some way to separate out CLA'd PECL modules to elsewhere but leave the PECL structure in place for those modules. It's important to offer at least that much, because as long as the licensing is sound, CLA'd or not CLA'd doesn't impact end users - just contributors.
Andi wrote that having the various companies host their own driver development and 'gift' their releases freely to PHP/PECL would be likely to impact consistency, i.e. would make this whole exercise pointless. Having them all hosted elsewhere means it's no longer a community exercise, in any respect. From that perspective, it's important that the drivers are hosted *somewhere* on php.net.
How about this one: there's PECLA (I like my babies), where CLA'd development takes place. pecla/module commit info goes to the pecl-cvs list, as with pecl/module commit info. On release, a PECLA module is no longer under CLA. It's copied to PECL, becomes a standard PECL module and is subject to all the normal PECL ins-and-out. PECLA development is effectively read-only, but _all_ of PECL development is open access. CLA'd modules currently in PECL would be moved to PECLA.
The only work needed to make that happen would be a new module set up in CVS (note: the PECLA module itself doesn't need to be CLA'd) and commit news for it forwarded to pecl-cvs.
- Steph
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
