Re: [PDO] [RFC] An Idea for PDO 2
| From: | Marcus Boerger | Date: | Sat, 02 Feb 2008 12:50:24 +0000 |
| Subject: | Re: [PDO] [RFC] An Idea for PDO 2 | ||
| References: | 1 2 3 4 | Groups: | php.internals php.pdo |
| Request: | Send a blank email to pdo+get-89@lists.php.net to get a copy of this message | ||
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