# Fw: [PDO] [RFC] An Idea for PDO 2 - Thread: https://externals.io/message/35106 - Original archive: https://news-web.php.net/php.internals/35106 - Started by Steph Fox on 2008-02-02T17:36:23+00:00 - Messages: 20 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #35106 — Steph Fox — 2008-02-02T17:36:23+00:00 URL: https://externals.io/message/35106#35106 > If we're going the PECL refurbishment route, can we have some way of > marking non-standard (as in CLA'd or differently-licensed) extensions to > make contributors' lives easier and future discussions of this nature > moot? Possibly even a separate CVS module that hooks into the PECL > infrastructure? e.g. PECLA ? :) This seemed a bad idea to me last night, but actually it could work out well (assuming PECL itself is sorted out pronto). From the end user perspective there'd be no distinction between PECL and PECLA extensions - both would have pecl.php.net homepages and releases etc - but from the dev perspective there's this whole marked area that you know you're going to need to sign something if you want to contribute to it, and it would require a separate checkout. It also has the advantage that we don't need to wait for PECL to be fixed before opening up the repository module, although obviously how well it works would be down to how well PECL resolves its problems. Thoughts, anyone? - Steph --- ## #35108 — Marcus Boerger — 2008-02-02T19:44:06+00:00 URL: https://externals.io/message/35106#35108 · In reply to: #35106 Hello Steph, all we need is to extend the PECL database with a license type field and a CLA flag. Nothing else is required at that end. But we should still move as much from php-src/ext to pecl as we can. marcus Saturday, February 2, 2008, 6:36:23 PM, you wrote: > > […] > e.g. PECLA ? :) > This seemed a bad idea to me last night, but actually it could work out well > (assuming PECL itself is sorted out pronto). From the end user perspective > there'd be no distinction between PECL and PECLA extensions - both would > have pecl.php.net homepages and releases etc - but from the dev perspective > there's this whole marked area that you know you're going to need to sign > something if you want to contribute to it, and it would require a separate > checkout. > It also has the advantage that we don't need to wait for PECL to be fixed > before opening up the repository module, although obviously how well it > works would be down to how well PECL resolves its problems. > Thoughts, anyone? > - Steph Best regards, Marcus --- ## #35109 — Steph Fox — 2008-02-02T19:52:44+00:00 URL: https://externals.io/message/35106#35109 · In reply to: #35108 > all we need is to extend the PECL database with a license type field and > a > CLA flag. Nothing else is required at that end. But we should still move > as > much from php-src/ext to pecl as we can. Hm but then when you checked out you'd have CLA'd stuff as well as normal PECL stuff, as now. Don't you find you automatically tend to fix things if they're broken? I know I do... even if I rarely get around to posting those fixes (because once everything works here I go on to the stuff I wanted to do and forget there was even a problem, until the next time.) I was just trying to find a way that would be acceptable to php.net and also would mean PDO2 driver development doesn't have to wait on PECL process decisions, but actually my off-list feedback says even a PECLA module wouldn't be an acceptable option for some. - Steph > marcus --- ## #35113 — Pierre Joye — 2008-02-02T20:33:13+00:00 URL: https://externals.io/message/35106#35113 · In reply to: #35109 Hi, > > […] There is no place for CLA in pecl either. I still see zero reason to tolerate CLA in pecl.php.net or anywhere else. > I was just trying to find a way that would be acceptable to php.net and also > would mean PDO2 driver development doesn't have to wait on PECL process > decisions, but actually my off-list feedback says even a PECLA module > wouldn't be an acceptable option for some. It is not OK for me (to list one). The last attempt to create this exact solution (flag in pecl with automatic download of pdf to sign etc.) was sadly a failure. As it begins well, the communication between the company and us was not good at all and it was not possible to get answers in a reasonable time or simply no answer at all. Wez was also involved and was the initial contact between the company and php. -- Pierre http://blog.thepimp.net | http://www.libgd.org --- ## #35116 — Marcus Boerger — 2008-02-02T23:16:00+00:00 URL: https://externals.io/message/35106#35116 · In reply to: #35109 Hello Steph, you would not checkout php-default. That would only be used for release management. Instead you would checkout php-src and whatever pecl modules you wanted, just as you do today. And that includes that you can choose whether you like CLA modules or not. Just as today you do not get all PECL modules. marcus Saturday, February 2, 2008, 8:52:44 PM, you wrote: > > […] > Hm but then when you checked out you'd have CLA'd stuff as well as normal > PECL stuff, as now. Don't you find you automatically tend to fix things if > they're broken? I know I do... even if I rarely get around to posting those > fixes (because once everything works here I go on to the stuff I wanted to > do and forget there was even a problem, until the next time.) > I was just trying to find a way that would be acceptable to php.net and also > would mean PDO2 driver development doesn't have to wait on PECL process > decisions, but actually my off-list feedback says even a PECLA module > wouldn't be an acceptable option for some. > - Steph > > […] Best regards, Marcus --- ## #35117 — Marcus Boerger — 2008-02-02T23:18:30+00:00 URL: https://externals.io/message/35106#35117 · In reply to: #35113 Hello Pierre, amen!, You're noted as no. But other people see a reason and continue to discuss *please* without you. We will take your vote in as no when it comes to voting if ever. If you are interested in explanations then I suggest you read all mails and blogs again until you understand the reason why some peole need a CLA. marcus Saturday, February 2, 2008, 9:33:13 PM, you wrote: > Hi, > > > […] > There is no place for CLA in pecl either. I still see zero reason to > tolerate CLA in pecl.php.net or anywhere else. > > […] > It is not OK for me (to list one). The last attempt to create this > exact solution (flag in pecl with automatic download of pdf to sign > etc.) was sadly a failure. As it begins well, the communication > between the company and us was not good at all and it was not possible > to get answers in a reasonable time or simply no answer at all. Wez > was also involved and was the initial contact between the company and > php. > -- > Pierre > http://blog.thepimp.net | http://www.libgd.org Best regards, Marcus --- ## #35120 — Pierre Joye — 2008-02-02T23:51:03+00:00 URL: https://externals.io/message/35106#35120 · In reply to: #35117 > Hello Pierre, > > amen!, You're noted as no. But other people see a reason and continue to > discuss *please* without you. Sorry, are you saying that the discussions are restricted to only a few chosen? All your arguments in your recent posts about openness and transparent process are rather pointless now. You may be pragmatic, but for your convictions, there is room for improvements. > We will take your vote in as no when it comes to voting if ever. And now you consider that discussions about what will happen in php.net, pecl.php.net and php core can happen suddenly in a newly created list and some people does not have to participate or are not welcome. What a wonderful example of what you have in mind for the future of the php.net projects and how they should work. > If you are interested in explanations then I suggest you > read all mails and blogs again until you understand the reason why some > peole need a CLA. Blog posts are not the way we communicate within a project sorry. All mails I read did not give reasons why a CLA is required for us and what benefits we will get. All one can read is only about external entities not able to contribute because the lack of CLA, absolutely no details about who they are, what are their real needs and expectations . The biggest problem is that they did not think that informing us via the normal way would have been expected. If the process was transparent and if all parties were actually discussing it then yes, I would have been more open and even helped to provide the tools in the pecl web site or in other parts of our sites. But how it goes, it is more the perfect example of a complete opaque process and confirm everything we can think about such additions. -- Pierre http://blog.thepimp.net | http://www.libgd.org --- ## #35122 — Marcus Boerger — 2008-02-03T00:46:11+00:00 URL: https://externals.io/message/35106#35122 · In reply to: #35120 Hello Pierre, I spoke about you as you left no room for discussions. You are not willing to compromise in any way, nor are you willing to be productive in any way. So there is no way in keeping you in discussions, is there? And no, we are no having any closed discussions. But we are having discussions because we want progress, productivity and we like to get more help. marcus Sunday, February 3, 2008, 12:51:03 AM, you wrote: > > > […] > Sorry, are you saying that the discussions are restricted to only a > few chosen? All your arguments in your recent posts about openness and > transparent process are rather pointless now. You may be pragmatic, > but for your convictions, there is room for improvements. > > […] > And now you consider that discussions about what will happen in > php.net, pecl.php.net and php core can happen suddenly in a newly > created list and some people does not have to participate or are not > welcome. What a wonderful example of what you have in mind for the > future of the php.net projects and how they should work. > > […] > Blog posts are not the way we communicate within a project sorry. All > mails I read did not give reasons why a CLA is required for us and > what benefits we will get. All one can read is only about external > entities not able to contribute because the lack of CLA, absolutely no > details about who they are, what are their real needs and expectations > . The biggest problem is that they did not think that informing us via > the normal way would have been expected. > If the process was transparent and if all parties were actually > discussing it then yes, I would have been more open and even helped to > provide the tools in the pecl web site or in other parts of our sites. > But how it goes, it is more the perfect example of a complete opaque > process and confirm everything we can think about such additions. > -- > Pierre > http://blog.thepimp.net | http://www.libgd.org Best regards, Marcus --- ## #35123 — Steph Fox — 2008-02-03T02:19:42+00:00 URL: https://externals.io/message/35106#35123 · In reply to: #35116 Personally I do a full pecl checkout alongside my php-src checkout, every time. The problems with that tend to come out during the build. ----- Original Message ----- From: "Marcus Boerger" To: "Steph Fox" Cc: ; "internals" Sent: Saturday, February 02, 2008 11:16 PM Subject: Re: [PDO] Re: [PHP-DEV] Fw: [PDO] [RFC] An Idea for PDO 2 > Hello Steph, > > you would not checkout php-default. That would only be used for release > management. Instead you would checkout php-src and whatever pecl modules > you > wanted, just as you do today. And that includes that you can choose > whether > you like CLA modules or not. Just as today you do not get all PECL > modules. > > marcus > > Saturday, February 2, 2008, 8:52:44 PM, you wrote: > > > […] > > > […] > > > […] > > > […] > > > […] > > > > > Best regards, > Marcus --- ## #35125 — Markus Fischer — 2008-02-03T08:04:57+00:00 URL: https://externals.io/message/35106#35125 · In reply to: #35122 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, sorry to jump into here Marcus Boerger wrote: | I spoke about you as you left no room for discussions. You are not willing | to compromise in any way, nor are you willing to be productive in any way. | So there is no way in keeping you in discussions, is there? And no, we are | no having any closed discussions. But we are having discussions because we | want progress, productivity and we like to get more help. But, Marcus, this sounds very strange. Unless someone shares the same ideology with you he is being escorted away from the discussions? Your point about Pierre "You are not willing to compromise in any way, nor are you willing to be productive in any way." is something I can absolutely not follow. I've read every single email. Just because you could not convince him with your ideas (or, for the matter, the ideas of the newly suggested process from Wez and others) does *not* mean is in unwilling. It simply means you have not found arguments to convince him. The only thing I can read between the lines is some kind of impatience and, please excuse my wording but is on purpose, it sounds immature. Long to short: "Unless you think the way we think, we don't want you here." You make it sound like "progress, productivity and get more help" is only accepted in the direction you're heading. But for openness and democracy this is not acceptable. thanks for reading this, - - Markus -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHpXWp1nS0RcInK9ARAnBZAJ928I83vNN23bhkXZ82mowy6VuV9QCeI3Q5 oQ98shWUEDyOoyC3GgR+8YM= =uquW -----END PGP SIGNATURE --- ## #35129 — Lukas Kahwe Smith — 2008-02-03T09:39:25+00:00 URL: https://externals.io/message/35106#35129 · In reply to: #35125 Hi, I know I have been guilty of formulating my concerns about PDO's history in an unfortunate way that turned out to sound more like a personal attack on Wez, than a sound technical commentary (which is all that counts on an OSS mailinglist). So I cannot pretend to have a white vest in this regard. However lets not venture there again. I think what Marcus was trying to say is that he wants to continue the discussion and he felt that Pierre was trying to shut it down. Now from what I gather from Pierre, he is simply still not convinced. Its not like Pierre is against "the evil cooperations" as is illustrated by the countless times he has helped people get things going with their PECL packages regardless of their background (cooperate or just private interest). So once again lets make an extra effort to stay clear of personal attacks. As such I was very happy when Marcus clarified that he did not feel personally attacked by Tony's comments. Because yes, most of us knew what Tony was expressing and it certainly wasn't an attack. Though without knowing him it might have sounded like that. regards, Lukas --- ## #35131 — Marcus Boerger — 2008-02-03T10:53:52+00:00 URL: https://externals.io/message/35106#35131 · In reply to: #35125 Hello Markus, none of what you said is what I wrote. If you knew me than you would know that I would never go this route. In fact I have always been open for discussions. However in this particular case we are speaking about absolute blockage. He is not willing to even discuss but rather shuts down any ongoing effort to make progress. Ok, you can be against all our ideas in any form but you have to understand what and why we discuss and since noone owns PHP as a single person no single person has the right to decide. So all we can do is participating in discussions and finding workable solutions. If someone is not willing to do so then all we can do is count the vote and respect it. But it is not acceptable to continously trying to prevent any ongoing efforts. marcus Sunday, February 3, 2008, 9:04:57 AM, you wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > Hello, > sorry to jump into here > Marcus Boerger wrote: > | I spoke about you as you left no room for discussions. You are not willing > | to compromise in any way, nor are you willing to be productive in any way. > | So there is no way in keeping you in discussions, is there? And no, we are > | no having any closed discussions. But we are having discussions because we > | want progress, productivity and we like to get more help. > But, Marcus, this sounds very strange. Unless someone shares the same ideology > with you he is being escorted away from the discussions? > Your point about Pierre "You are not willing to compromise in any way, nor are > you willing to be productive in any way." is something I can absolutely not > follow. I've read every single email. Just because you could not convince him > with your ideas (or, for the matter, the ideas of the newly suggested process > from Wez and others) does *not* mean is in unwilling. > It simply means you have not found arguments to convince him. > The only thing I can read between the lines is some kind of impatience and, > please excuse my wording but is on purpose, it sounds immature. > Long to short: "Unless you think the way we think, we don't want you here." > You make it sound like "progress, productivity and get more help" is only > accepted in the direction you're heading. But for openness and democracy this > is not acceptable. > thanks for reading this, > - - Markus > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > iD8DBQFHpXWp1nS0RcInK9ARAnBZAJ928I83vNN23bhkXZ82mowy6VuV9QCeI3Q5 > oQ98shWUEDyOoyC3GgR+8YM= > =uquW > -----END PGP SIGNATURE----- Best regards, Marcus --- ## #35134 — Pierre Joye — 2008-02-03T13:47:38+00:00 URL: https://externals.io/message/35106#35134 · In reply to: #35131 Hi Markus, > Hello Markus, > > none of what you said is what I wrote. If you knew me than you would know > that I would never go this route. In fact I have always been open for > discussions. That's new. > However in this particular case we are speaking about absolute > blockage. Please re read my posts. Answer the questions, then a discussion may begin. For now, there is nothing new since the very first posts outside you changing your mind. > He is not willing to even discuss but rather shuts down any > ongoing effort to make progress. Ok, you can be against all our ideas in any > form When you were bashing IBM about their ODBC contribution to PECL on IRC, I was helping them to package and release their softwares via PECL. So stop to spread FUDs about me or what I do, and from now on. Not that what you may think about me or not matters, but every reader here does not know all the backgrounds behind you or me. If you have griefs, feel free to mail me them (all at once) or tell them to me directly when you come around here, even in German if it is easier. > but you have to understand what and why we discuss and since noone owns > PHP as a single person no single person has the right to decide. So all we > can do is participating in discussions and finding workable solutions. If > someone is not willing to do so then all we can do is count the vote and > respect it. But it is not acceptable to continously trying to prevent any > ongoing efforts. I do not continuously prevent ongoing effort. I'm more prudent than you when it comes to such decisions. What I asked should have been answered or even better, I would not have to ask such obvious questions if this request was done in a respectful manner. 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). Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org --- ## #35138 — Steph Fox — 2008-02-03T18:24:46+00:00 URL: https://externals.io/message/35106#35138 · In reply to: #35134 > 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 --- ## #35140 — Lukas Kahwe Smith — 2008-02-03T18:52:21+00:00 URL: https://externals.io/message/35106#35140 · In reply to: #35138 > > […] > > 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.) Right .. for example we have not yet heard from anyone from Microsoft .. > 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. Well thanks to a separate PEAR channel, we have all the infrastructure easily setup to have a different place for users to pick up the code. Or are you more concerned about the CVS, than the distribution of the packages? > 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. Why copy to PECL in this case? Shouldnt it just be part of the PHP distribution QA process? > regards, Lukas --- ## #35141 — Steph Fox — 2008-02-03T19:04:10+00:00 URL: https://externals.io/message/35106#35141 · In reply to: #35140 Moin Lukas, > > […] > > Well thanks to a separate PEAR channel, we have all the infrastructure > easily setup to have a different place for users to pick up the code. Or > are you more concerned about the CVS, than the distribution of the > packages? Eh? No, I'm concerned about binaries in the Windows version. We just don't have a working pecl install option. If anyone wants CVS they can use cvs or tortoisecvs or whatever, but that's irrelevant to users... > Why copy to PECL in this case? Shouldnt it just be part of the PHP > distribution QA process? Nobody liked my original PECLA idea (separate CVS module for CLA'd stuff but all PECL resources shared), so I'm trying to give it a different angle :) I preferred the first version tho'. - Steph --- ## #35142 — Lukas Kahwe Smith — 2008-02-03T19:10:23+00:00 URL: https://externals.io/message/35106#35142 · In reply to: #35141 > Moin Lukas, > > > […] > > Eh? No, I'm concerned about binaries in the Windows version. We just > don't have a working pecl install option. If anyone wants CVS they > can use cvs or tortoisecvs or whatever, but that's irrelevant to > users... Well Greg has long been talking about adding the ability to bundle binaries in PECL packages. Not sure if this is included in the next generation installer Pyrus. Again, I personally do not think that the distribution we ship would be so radically different, so this would not be an issue that would increase in importance. However sure, making it easy to get binaries to people who cannot compile would be a great thing for PECL in general. regards, Lukas --- ## #35143 — Steph Fox — 2008-02-03T19:11:55+00:00 URL: https://externals.io/message/35106#35143 · In reply to: #35141 Ah sorry - I'm not good with multi-tasking, mixed up two ongoing conversations here. > > […] I don't have concerns about a PECLA module utilizing the existing PECL infrastructure in any way. Do you? - Steph --- ## #35144 — Steph Fox — 2008-02-03T19:20:37+00:00 URL: https://externals.io/message/35106#35144 · In reply to: #35142 Hi Lukas, > Well Greg has long been talking about adding the ability to bundle > binaries in PECL packages. Not sure if this is included in the next > generation installer Pyrus. Again, I personally do not think that the > distribution we ship would be so radically different, so this would not > be an issue that would increase in importance. However sure, making it > easy to get binaries to people who cannot compile would be a great thing > for PECL in general. I see it more as 'crucial' than as 'a great thing'. The point of the installer is that it has a means of determining status... this is something that can't be addressed in a big zip archive containing every PECL extension that will compile against a given PHP branch. Once we have that, it becomes sensible to talk about shipping 'recommended modules' in a single (much smaller) zip at the point of release. And _then_ we can talk about moving all non-essential items out of core. - Steph > > regards, > Lukas > > -- > PDO Working Group Mailing List (http://pdo.php.net) --- ## #35161 — Derick Rethans — 2008-02-04T09:26:22+00:00 URL: https://externals.io/message/35106#35161 · In reply to: #35143 > > […] > > I don't have concerns about a PECLA module utilizing the existing PECL > infrastructure in any way. Do you? I do, as it requires maintenance from the PHP project for non-open source code. I find that a bit strange. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org