Re: [PHP-DEV] Re: [PDO] [RFC] An Idea for PDO 2

Be fair, this is an open list. Anyone can join it, and it keeps the noise 
levels down on internals@. Please? ;)

http://news.php.net/php.pdo

- Steph

----- Original Message ----- 
From: "Marcus Boerger" <[email protected]>
To: "Wez Furlong" <[email protected]>
Cc: "Steph Fox" <[email protected]>; <[email protected]>; 
<[email protected]>
Sent: Saturday, February 02, 2008 12:50 PM
Subject: [PHP-DEV] Re: [PDO] [RFC] An Idea for PDO 2


> Hello Wez,
>
>  keeping the discussion on this list is a major mistake. And it is 
> actually
> the reason why everyone outside this list is against it. And whether you
> read blogs or not does not interest anybody at all - unless you are going 
> to
> comment on every single blog that mentions PHP and CLA. So far PHP is open
> source! Respect this please!! Open means open!!!
>
> I am crossposting to internals again. People should know what is going on.
> Otherwise we could simply sign NDAs and be done.
>
> marcus
>
> Saturday, February 2, 2008, 6:36:17 AM, you wrote:
>
>> On Feb 1, 2008, at 10:24 PM, Steph Fox wrote:
>
>>> Wez,
>>>
>>> The only difference between my initial proposal, the one Ben Ramsey
>>> posted and this one from Marcus is that they're getting more
>>> complex, *without anyone actually discussing anything at all*.
>
>> On the contrary, there's been plenty of discussion going on.  Despite
>> my request that we keep the discussion on this list, people have been
>> talking to each other in real life, on the phone, talking on IRC, IM,
>> posting thoughts and comments to blogs and so forth.  Some comments
>> positive, some negative, but discussion nonetheless.
>
>> I've been making an effort to read the various blog entries, even
>> those in foreign languages (thanks to a combination of blog searching
>> tools and google translation tools) and keep an eye on IRC when I have
>> a spare minute or two.
>
>
>>> ... He had a response from Jay, who said this had already been
>>> discussed. According to him,
>>>
>>> "There was some dissent among members about the core and the spec/
>>> API docs being non-CLA'd which is why the proposal is currently the
>>> way it is.  I know that various legal teams had concerns about PDO
>>> core not being under CLA, but if a case is made in the community for
>>> this, perhaps minds may change."
>>>
>>> Now you're saying there's no problem with this approach? Where's the
>>> real discussion going on?
>
>> No, I didn't say that there's no problem, I said that this sounds
>> reasonable.
>
>> For example, a problem with this general solution is still that
>> database experts from multiple sources would not be able to directly
>> co-operate on the PDO core.  However, it sounds to me like a
>> reasonable (though sub-optimal, from a technical and productivity
>> point of view) compromise to be able to accept feedback and
>> suggestions and have those gated through the PDO core maintainers.
>
>> That's just my opinion; I certainly don't speak for anyone else.
>
>>> It's not a bad thing per se to separate PECL and PHP, but it does
>>> beg the question of how to approach distributions/snaps, which is
>>> AFAICS the only reason anything not essential to PHP itself is in
>>> the core in the first place. Nobody's sat down and worked it through
>>> properly, despite Lukas' repeated requests.
>
>> One reason that no one has discussed that is because it is not
>> directly related to the question of PDO and how to best get the
>> vendors involved.  Once we've figured that out, we can iron out the
>> details of the implementation.
>
>>> I think if we did this it would have to be as part of a broader
>>> approach, with a full re-evaluation of the PHP/PECL relationship,
>>> some hard thinking about distribution mechanisms for PECL, and some
>>> serious decisions about setup recommendations. It's really not the
>>> quick fix it appears to be... and making it so without putting that
>>> effort into it would hit the PHP userbase harder than anyone else.
>
>> And that's well beyond the scope of PDO.  Remember, one of the
>> concerns raised by the community was that this business would
>> interfere with the rest of PHP; the suggestions we've made so far have
>> been intentionally very focused to avoid getting into that.
>
>> Again; first let's see if we can find an acceptable way to take their
>> contributions before moving on to those finer points.
>
>>> BTW I'm still waiting to hear about the other alternatives that were
>>> discussed behind our backs, and the objections against them... and I
>>> say 'behind our backs' simply because nobody seems to want to tell us!
>
>> We talked about whether the various vendors could work on various
>> combinations of pieces of the code if they were or were not CLA'd.
>> I'm sure you don't really need me to list the various combinations of
>> CLA, not CLA, in PHP, in PECL, outside of PHP, and hosted individually
>> by the vendors.  It was not a very exciting discussion.
>
>> The main realization was that the vendors could not co-operate with
>> each other on code without a CLA in place, and that some of them would
>> not be able to co-operate with the community without a CLA in place.
>
>> --Wez.
>
>
>
>
> Best regards,
> Marcus
>
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>