Newsgroups: php.internals,php.pdo
Path: news.php.net
Xref: news.php.net php.internals:35138 php.pdo:111
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain zend.com from 64.97.136.173 cause and error)
Message-ID: <00b301c86692$0f065230$c6fc1f3e@foxbox>
Reply-To: "Steph Fox" <steph@zend.com>
To: "Pierre Joye" <pierre.php@gmail.com>,
	"Marcus Boerger" <helly@php.net>
Cc: "Markus Fischer" <markus@fischer.name>,
	<pdo@lists.php.net>,
	"internals" <internals@lists.php.net>
References: <00ce01c865c2$22f23aa0$c6fc1f3e@foxbox> <510220265.20080202204406@marcus-boerger.de> <019c01c865d5$2ebbacf0$c6fc1f3e@foxbox> <fe05d1540802021233n14dca604s413a750b9a52d0a7@mail.gmail.com> <155955105.20080203001830@marcus-boerger.de> <fe05d1540802021551l704ac0d9k435772b69da50295@mail.gmail.com> <1497821512.20080203014611@marcus-boerger.de> <47A575A9.7060903@fischer.name> <304490699.20080203115352@marcus-boerger.de> <fe05d1540802030547p46a53a68hb0c5e79573d025ae@mail.gmail.com>
Date: Sun, 3 Feb 2008 18:24:46 -0000
Organization: Zend Technologies
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit
Subject: Re: [PDO] Re: An Idea for PDO 2
From: steph@zend.com ("Steph Fox")

> 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