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
