Hello all,
So after the initial uproar on last week's attempts to put parts
of PHP development under the terms of a CLA, a bunch of us actually
spent some time in finding solutions for one way or the other. I
don't want to bother you with more details on the why.
One thing for certain, we want PDO.
As the reasoning, this was discussed enough, so I'll jump directly
to my ideas for a solution.
- Develop a PECL CLA that can optionally be used for PECL projects.
- If necessary, adapt the PHP License, so that it works nicely
together with the CLA. - The projects that want a CLA can choose between the PHP License or
LGPL. - Change the PELC web site so that projects can opt-in to using the
CLA. - Arrange it so that projects cannot drop the CLA flag.
- Add a user/CLA/project table to the PHP user database, and use this
in CVS ACLs. - Create a new CVS module php-default.
- Move all extensions that can be disabled and are not required for
others to PECL. - Link everything under php-src plus a default selection of
extensions to php-default. - Let us once and for all ban CLAs from php-src aka PHP core.
- Start developing PDO as part of CVS module php-src.
Sorry for not writing this earlier. So how does this idea sound?
Best regards,
Marcus
p.s.: Post comments as reply or here: http://blog.somabo.de/2008/02/we-want-pdo-don-we.html#links
Hey Marcus—
- Develop a PECL CLA that can optionally be used for PECL projects.
- If necessary, adapt the PHP License, so that it works nicely
together with the CLA.
IMO (and FWIW), CLAs do not belong in any official php.net project. I
have already explained the reason why in the past, so I won't repeat
myself, but a CLA violates the basic principle under which everything
"officially" PHP is developed, and it should not be allowed to enter
the project in any way.
Perhaps PDO2 can simply be an external project, maybe hosted at
Sourceforge or some other such site?
Marco
Hi,
Globally -1. I'm against any CLA in php.net. It was a mistake in the
first place to accept restricted modules. There is many repositories
out there, and the companies that need a CLA also have the resources
to create their own PECL channels. But they may not have the fantastic
advantages brought by being in php.net, like QA, visibility, etc.
Secondly it is not correct to mix the topics. PDO will have a future,
no matter if we accept a CLA or not. The same companies (I would like
to say, the company) will participate anyway. Their customers need it.
I think this quote fits well in this thread:
"Those who would give up Essential Liberty to purchase a little
Temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin, 1759
--
Pierre
http://blog.thepimp.net | http://www.libgd.org
Sorry for not writing this earlier. So how does this idea sound?
It sounds quite bad.
If you want to do something good for PHP - either respect its rules, or go away.
Changing the rules to fit your needs is not acceptable.
--
Wbr,
Antony Dovgal
Sorry for not writing this earlier. So how does this idea sound?
It sounds quite bad.
If you want to do something good for PHP - either respect its rules, or go away.
Changing the rules to fit your needs is not acceptable.
I don't have a particular horse to back in this race, and I realize
people are passionate on both sides, but can we please have a polite
discussion on this topic?
We change the rules all the time to fit the needs of PHP. This may not
be one of those times, or this may not be the way to go, but I think
the concept of having better support from database companies is one
that at least deserves the benefit of a dialog.
Clearly, there is an attempt from some people to listen to the vocal
feedback on the original PDO CLA proposal and try to come up with an
alternative. You may not still like it, which is totally your right,
but it's not as if what he's saying is completely tone deaf to what's
going on.
Furthermore, I think Marcus has contributed enough to PHP that he does
not deserve to hear that what would be good for PHP is for him to "go
away." PDO opinions aside, I don't think any of us would actually
think that would put PHP in a more healthy situation.
Thanks.
-adam
--
adam@trachtenberg.com | http://www.trachtenberg.com
author of o'reilly's "upgrading to php 5" and "php cookbook"
avoid the holiday rush, buy your copies today!
On Feb 1, 2008 11:10 PM, Adam Maccabee Trachtenberg
adam@trachtenberg.com wrote:
Sorry for not writing this earlier. So how does this idea sound?
It sounds quite bad.
If you want to do something good for PHP - either respect its rules, or go away.
Changing the rules to fit your needs is not acceptable.I don't have a particular horse to back in this race, and I realize
people are passionate on both sides, but can we please have a polite
discussion on this topic?
There was nothing not polite in Tony's reply.
Furthermore, I think Marcus has contributed enough to PHP that he does
not deserve to hear that what would be good for PHP is for him to "go
away." PDO opinions aside, I don't think any of us would actually
think that would put PHP in a more healthy situation.
The targets were these/this companies(y) pushing CLA in php.net when
it is not necessary to contribute. It has been proven already since
months on a nearly daily basis.
For example:
http://blogs.oracle.com/opal/discuss/msgReader$268
and the numerous contributions from IBM people.
--
Pierre
http://blog.thepimp.net | http://www.libgd.org
Hello Pierre,
in some places of the world what he wrote might be ok in the way he
wrote it. In some this wouldn't be acceptable at all. Contributing to PHP
for a long time now and knowing Tony I a) couldn't care less and b) guess I
know what he wanted to say and prefer to understand it as such.
Either way, this is a polictical & strategical move. One that has a bunch of
implications for which most peolple would need to read three times at least
to understand them all.
marcus
Friday, February 1, 2008, 11:20:33 PM, you wrote:
On Feb 1, 2008 11:10 PM, Adam Maccabee Trachtenberg
adam@trachtenberg.com wrote:Sorry for not writing this earlier. So how does this idea sound?
It sounds quite bad.
If you want to do something good for PHP - either respect its rules, or go away.
Changing the rules to fit your needs is not acceptable.I don't have a particular horse to back in this race, and I realize
people are passionate on both sides, but can we please have a polite
discussion on this topic?
There was nothing not polite in Tony's reply.
Furthermore, I think Marcus has contributed enough to PHP that he does
not deserve to hear that what would be good for PHP is for him to "go
away." PDO opinions aside, I don't think any of us would actually
think that would put PHP in a more healthy situation.
The targets were these/this companies(y) pushing CLA in php.net when
it is not necessary to contribute. It has been proven already since
months on a nearly daily basis.
For example:
http://blogs.oracle.com/opal/discuss/msgReader$268
and the numerous contributions from IBM people.
--
Pierre
http://blog.thepimp.net | http://www.libgd.org
Best regards,
Marcus
Hello Pierre,
in some places of the world what he wrote might be ok in the way he
wrote it.
In every places in the world you have to respect the existing rules
and usages or you better have to leave if you don't want to. That does
not mean that you can't have an influence on them once you are in.
In some this wouldn't be acceptable at all. Contributing to PHP
for a long time now and knowing Tony I a) couldn't care less and b) guess I
know what he wanted to say and prefer to understand it as such.
c) you know exactly what he meant and who are (is) the target.
Either way, this is a polictical & strategical move. One that has a bunch of
implications for which most peolple would need to read three times at least
to understand them all.
Exactly and I see absolutely nothing that can change my view or
opinion on this topic. There is other very large projects out there
where major or leading companies contribute, there is no CLA, there is
no restriction. In some cases, they are even kept outside as long as
they don't want to follow the usages and rules of the given projects.
That being said, where are the complains? Who is actually pushing the
CLA in? I mean outside Zend and related? Why did they not post
something to actually explain their views? Or are they afraid to say
that they can't support PHP if there is no CLA? Well, I would be
afraid too, especially when I know that I have to support PHP anyway.
At least if I want to keep my piece of the web cake .
Cheers,
Pierre Joye wrote:
The targets were these/this companies(y) pushing CLA in php.net when
it is not necessary to contribute. It has been proven already since
months on a nearly daily basis.For example:
http://blogs.oracle.com/opal/discuss/msgReader$268
My understanding is that because of its collaborative nature,
contributing to PDO V2 has new and very different implications.
Arguments using past contributions to show the ad-hoc development
model is feasible are (unfortunately) not tenable.
Chris
--
Christopher Jones, Oracle
Email: christopher.jones@oracle.com Tel: +1 650 506 8630
Blog: http://blogs.oracle.com/opal/ Free PHP Book: http://tinyurl.com/f8jad
Hi Chris,
Pierre Joye wrote:
The targets were these/this companies(y) pushing CLA in php.net when
it is not necessary to contribute. It has been proven already since
months on a nearly daily basis.For example:
http://blogs.oracle.com/opal/discuss/msgReader$268My understanding is that because of its collaborative nature,
contributing to PDO V2 has new and very different implications.
You mean its collaborative and restrictive nature?
Arguments using past contributions to show the ad-hoc development
model is feasible are (unfortunately) not tenable
Again, please see my other posts. Since my last post, nothing has been
brought to the list to clarify the situation. Important questions like
who is asking a CLA, who will contribute and what will be brought on
board? Why did they not take contact with us? All these questions are
without answer and until they got one, I will not change my mind for a
yota (and I doubt any oposant will).
--
Pierre
http://blog.thepimp.net | http://www.libgd.org
Pierre Joye wrote:
Hi Chris,
Pierre Joye wrote:
The targets were these/this companies(y) pushing CLA in php.net when
it is not necessary to contribute. It has been proven already since
months on a nearly daily basis.For example:
http://blogs.oracle.com/opal/discuss/msgReader$268My understanding is that because of its collaborative nature,
contributing to PDO V2 has new and very different implications.You mean its collaborative and restrictive nature?
No - its collaborative nature.
Arguments using past contributions to show the ad-hoc development
model is feasible are (unfortunately) not tenableAgain, please see my other posts. Since my last post, nothing has been
brought to the list to clarify the situation. Important questions like
who is asking a CLA
That has already been stated. This is not an "us and them"
situation since each party has different requirements.
who will contribute and what will be brought on board?
That has also been stated: expertise and person-power.
The fine points will depend on the community, a term that includes data
access providers (I'm using that name since not all are actual "vendors"),
and the model the community chooses to accept.
Why did they not take contact with us?
We did. It just took a very long time. Think of it as a normal "is
this idea possible" chat that took place in very, very, very slow motion.
Chris
--
Christopher Jones, Oracle
Email: christopher.jones@oracle.com Tel: +1 650 506 8630
Blog: http://blogs.oracle.com/opal/ Free PHP Book: http://tinyurl.com/f8jad
Hi Chris,
Pierre Joye wrote:
Hi Chris,
Pierre Joye wrote:
The targets were these/this companies(y) pushing CLA in php.net when
it is not necessary to contribute. It has been proven already since
months on a nearly daily basis.For example:
http://blogs.oracle.com/opal/discuss/msgReader$268My understanding is that because of its collaborative nature,
contributing to PDO V2 has new and very different implications.You mean its collaborative and restrictive nature?
No - its collaborative nature.
Arguments using past contributions to show the ad-hoc development
model is feasible are (unfortunately) not tenableAgain, please see my other posts. Since my last post, nothing has been
brought to the list to clarify the situation. Important questions like
who is asking a CLAThat has already been stated. This is not an "us and them"
situation since each party has different requirements.who will contribute and what will be brought on board?
That has also been stated: expertise and person-power.
I think you are taking for a brain dead or some stupid PR out there.
Please answer the questions, don't give me buzz words to make a point.
The fine points will depend on the community, a term that includes data
access providers (I'm using that name since not all are actual "vendors"),
and the model the community chooses to accept.Why did they not take contact with us?
We did. It just took a very long time. Think of it as a normal "is
this idea possible" chat that took place in very, very, very slow motion.
There is no discussion, there is no chat. You (as group) simply refuse
to answer the most obvious questions.
Tell us the names of these entities, companies or persons, who are
going to contribute and what are actually their requirements. What
will they bring (saying "expertise" is not something I can buy)? I
don't understand what is so hard to understand that it is a minimum to
get before we can even discuss the CLA introduction. Let alone the
fact that they don't consider us as good enough as discussions
partner.
Cheers,
Tell us the names of these entities, companies or persons, who are
going to contribute and what are actually their requirements. What
will they bring (saying "expertise" is not something I can buy)? I
don't understand what is so hard to understand that it is a minimum to
get before we can even discuss the CLA introduction. Let alone the
fact that they don't consider us as good enough as discussions
partner.
Pierre does have a point here. We don't know who we're dealing with, what
they can/could offer, or what they want or need in order to offer it.. and
nobody's really tried to communicate with php.net apart from those already
in the php.net inner circle.
I believe there's more room for give and take than Pierre (and others) would
be prepared to acknowledge ATM, but if nobody's even prepared to talk with
php.net about the issues from their own perspective(s) how can we be
expected to work together to find a good solution?
In fairness it seems the corporate side all came together to exchange views
about how to restrict stuff and haven't reached their own 'group conclusion'
yet, but from this end the only message that can sanely be given at present
is 'do the best you can without restrictions, because we have good reasons
for disliking them'.
- Steph
Cheers,
Tell us the names of these entities, companies or persons, who are
going to contribute and what are actually their requirements. What
will they bring (saying "expertise" is not something I can buy)? I
don't understand what is so hard to understand that it is a minimum
to
get before we can even discuss the CLA introduction. Let alone the
fact that they don't consider us as good enough as discussions
partner.Pierre does have a point here. We don't know who we're dealing with,
what they can/could offer, or what they want or need in order to
offer it.. and nobody's really tried to communicate with php.net
apart from those already in the php.net inner circle.
Right, we know Wez, we know Andi, we know you. We know more and more
of the guys working on tests, we know know at least the emails of some
of the guys working on the currently CLA'ed IBM PDO drivers. I have
seen some Microsoft guys at some conferences. But I have never talked
to one in the context of PDO development. We also do not know who will
be coming from inside Oracle to work with us if we go the CLA way. We
do not know who will come from inside IBM to work with us etc. OSS is
a collaborative process that is not about some manager allocating some
ressources here and there. People usually make personal commitments
here and maybe this is the bigger culture clash than the CLA. What is
being proposed is to turn part of PHP into something that is managed
by a manager and the budget he gets allocated by a manager above him.
People do not commit access for saying what company they work for.
People get commit access once they have send enough patches that are
top notch, that php.net decides they can trust them. This is the model
of trust we have gone by. So if we are going to change this to start
trusting a managerial process, the least we can ask is to have some
interaction with the people that will most likely be involved there,
even if there is a good chance that things might be shuffled around by
the time we get to see code.
regards,
Lukas
Lukas Kahwe Smith wrote:
OSS is a collaborative process that is not about some manager
allocating some ressources here and there. People usually make
personal commitments here and maybe this is the bigger culture clash
than the CLA.
Oracle contributes to a range of open source projects, big and small,
mature and too new to be known. The commitments come at the personal
level and from management who expect their staff to work on those
projects.
OSS projects accept contributions on merit, and that doesn't always
mean knowing much about the background of the people contributing.
What is being proposed is to turn part of PHP into something that is
managed by a manager and the budget he gets allocated by a manager
above him.
The proposal is a broader approach to the design and implementation of
a DB access layer. Instead of a piecemeal, ad hoc set of designs that
ultimately reduces general productivity, I'd like to sit down and
discuss what users want and create a coherent solution.
People do not commit access for saying what company they work for.
People get commit access once they have send enough patches that are top
notch, that php.net decides they can trust them. This is the model of
trust we have gone by. So if we are going to change this to start
trusting a managerial process, the least we can ask is to have some
interaction with the people that will most likely be involved there,
even if there is a good chance that things might be shuffled around by
the time we get to see code.
The code and strength of contributions and maintenance is the ultimate
evidence of what can be trusted. Poor quality drivers, if they are
distributed via a PECL-only distribution, will acquire their own bad
reputation and remain little used like other dormant PECL extensions.
Or if the drivers are part of the core PHP distribution, a poor driver
should get pulled if it is not of sufficient quality as determined by
the PHP community.
I believe that all the data access providers potentially involved have
some level of skill with PHP extension writing, and they certainly
have some skill in writing software.
I hope that the data access providers are not the only people
contributing to, or gate-checking, the drivers.
Chris
--
Christopher Jones, Oracle
Email: christopher.jones@oracle.com Tel: +1 650 506 8630
Blog: http://blogs.oracle.com/opal/ Free PHP Book: http://tinyurl.com/f8jad
Hi Chris,
On Thu, Feb 14, 2008 at 10:08 PM, Christopher Jones
christopher.jones@oracle.com wrote:
The code and strength of contributions and maintenance is the ultimate
evidence of what can be trusted. Poor quality drivers, if they are
distributed via a PECL-only distribution, will acquire their own bad
reputation and remain little used like other dormant PECL extensions.
Or if the drivers are part of the core PHP distribution, a poor driver
should get pulled if it is not of sufficient quality as determined by
the PHP community.
As we all agree that poor drivers are not welcome (and great drivers
are...), the problem here is not about improving PHP database support
(call it PDOv2 or DBDOv3) but to introduce CLA'ed areas in PHP, php
core or PECL. It would be nice to dissociate the two and to begin a
real dialog between all parties (see my list of questions).
About the list having been already gaven, sorry but I can't remember
any list or any post about this topic not coming from existing
contributors. As I said, many times (not enough) Zend is not PHP. Zend
is a (big) contributor but Zend is not PHP. Neither are any of us.
Conferences and management meetings are great place to create personal
contacts and improve one thing or another, they are not the place to
decide such things for the whole community.
Cheers,
Pierre Joye wrote:
As we all agree that poor drivers are not welcome (and great drivers
are...), the problem here is not about improving PHP database support
(call it PDOv2 or DBDOv3) but to introduce CLA'ed areas in PHP, php
core or PECL. It would be nice to dissociate the two and to begin a
real dialog between all parties (see my list of questions).About the list having been already gaven, sorry but I can't remember
any list or any post about this topic not coming from existing
contributors.
There's a list of the organizations who have currently expressed
interest in http://www.php.net/~wez/pdo/pdo-faq.txt
Conferences and management meetings are great place to create
personal contacts and improve one thing or another, they are not the
place to decide such things for the whole community.
Nothing was decided other than the proposal that was presented for
the community to evaluate.
I think most multi-person plans that impact an existing OSS project
have had some genesis in private discussions before being broadcast.
For PDO V2, this discussion was just really slow and intermittent.
Chris
--
Christopher Jones, Oracle
Email: christopher.jones@oracle.com Tel: +1 650 506 8630
Blog: http://blogs.oracle.com/opal/ Free PHP Book: http://tinyurl.com/f8jad
I think most multi-person plans that impact an existing OSS project
have had some genesis in private discussions before being broadcast.
For PDO V2, this discussion was just really slow and intermittent.
Yeah, I am basically fine with this. I send private emails to people
around OSS projects all the time. Its absolutely ok and actually
something that is vital to keep things manageable.
However the point here is. There is a proposal on the table to change
the php.net project to be able to bring in developers we do not know,
for code they have not yet written, for specs they have not yet
contributed. This is flipping our development process upside down
while adding legal hurdles.
As such the only course of action I currently is to start working. If
you guys do not feel like you can work within the current legal bounds
of php.net, then I suggest you start working outside of them. Once we
see actual value being contributed, the willingness to compromise and
change will be much higher.
regards,
Lukas
Lukas Kahwe Smith wrote:
However the point here is. There is a proposal on the table to change
the php.net project to be able to bring in developers we do not know,
for code they have not yet written, for specs they have not yet
contributed. This is flipping our development process upside down while
adding legal hurdles.
Since the process hasn't started yet, of course some of the
participants aren't known. I don't think PDO V2 is going to be any
different from other PHP projects: it starts at the beginning and
progress is monitored. If it's not going well, people speak up and
decisions are made about how to correct it.
As such the only course of action I currently is to start working. If
you guys do not feel like you can work within the current legal bounds
of php.net, then I suggest you start working outside of them. Once we
see actual value being contributed, the willingness to compromise and
change will be much higher.
I want to see the effort spent will have value to the community.
Chris
--
Christopher Jones, Oracle
Email: christopher.jones@oracle.com Tel: +1 650 506 8630
Blog: http://blogs.oracle.com/opal/ Free PHP Book: http://tinyurl.com/f8jad
-----Original Message-----
From: Lukas Kahwe Smith [mailto:mls@pooteeweet.org]
Sent: Thursday, February 14, 2008 2:15 PM
To: Christopher Jones
Cc: Pierre Joye; pdo@lists.php.net; PHP Internals
Subject: Re: [PDO] Re: [PHP-DEV] Re: [PDO] Re: [PHP-DEV] Re: [PDO] Re:
[PHP-DEV] [RFC] An Idea for PDO 2
-snip-
As such the only course of action I currently is to start working. If
you guys do not feel like you can work within the current legal bounds
of php.net, then I suggest you start working outside of them. Once we
see actual value being contributed, the willingness to compromise and
change will be much higher.
It's a bit of a chicken&egg problem. The idea was to find a way for this
to happen which would work long term for the project. This includes both
the contribution process and then the distribution process.
Theoretically working on this separately is an option the same way you
have Propel for DB abstraction, Midnight Coders for Flex, NuSOAP for
SOAP, etc...
However we see this as an important core component for PHP and a lot of
these processes can't just be changed/reversed once they are set in
motion. For example, if this is developed separately then I assume
there'd be no problem in having a legal entity (you mentioned some of
the other standards bodies who are also entities). The issue will pop up
when there are successes and we all believe it's beneficial to roll it
into PHP. So instead we tried to come up with a proposal which would
enable the long term feasibility and create a feasible path ahead of
time. As an example with the legal entity issue we managed to get buy in
for using PHP Group (not trivial, or should I even say, unprecedented).
Anyway it's still an option but not the preferred one.
I'd be interested to hear more about the ideas people had on how we can
possibly decouple some of the packaging decisions and where the actual
work happens. There'd obviously still need to be certain requirements
including compatible licenses, integration into bug tracker (possibly),
and configuration management guidelines, but maybe others have ideas for
ways to accomplish the goals in a way which could still work for most
people and allow the vendors to have some of their best people to fully
participate. I say most because 100% of people are never happy including
in all the million other discussions we have had on other topics over
the years.
Anyway, let's continue this discussion but with the intent to make a
best shot at some ideas for how to achieve some of the goals I think the
majority of us would like to see a PDO which includes a first-class PDO
with the necessary functionality and consistency, high-quality and
consistent drivers across all data access APIs, and well documented
functionality.
Andi
Greetings, PDO community! My name is David Sceppa and I am a program manager working at Microsoft on improving SQL Server for PHP data hosting.
Let me first just say that Microsoft is very interested in participating in the PDO 2 effort and I plan to actively engage in the discussions of the spec and the core via the mailing list. As a relative newcomer to this space, Microsoft is highly incented to see a single solution that serves the needs of this community. This is both from the standpoint of technical investment (i.e. we would like to focus our resources on delivering one rock solid answer rather than many across the space), and for customer clarity as having too many choices often winds up being confusing. We believe that PDO 2 is that solution going forward in the PHP space, and we are therefore committed to seeing it through to fruition.
The approach that's been described in proposals (vendor-built drivers can be covered via CLAs while the core components remain CLA-free) is something I believe to be in the best interests of both driver writers and the developers who use PDO. We would prefer to have the spec and the core covered by CLA, so that we can make more direct contributions, yet we understand that the community wishes to keep the spec and the core CLA-free.
Microsoft has a great deal of experience and lessons learned (both positive and negative) through the evolution of ODBC and other data access technologies that give us a unique perspective and we look forward to contributing to the PDO 2 effort. I look forward to diving into more technical discussions on the mailing list on issues such as whether or not there should be a set of core PDO libraries, the PDO metadata vocabulary, driver extensibility, etc.
David Sceppa
Program Manager, SQL Server Driver for PHP
Microsoft
The approach that's been described in proposals (vendor-built drivers can
be covered via CLAs while the core components remain CLA-free) is something
I believe to be in the best interests of both driver writers and the
developers who use PDO. We would prefer to have the spec and the core
covered by CLA, so that we can make more direct contributions, yet we
understand that the community wishes to keep the spec and the core
CLA-free.
I am curious. If PDO core itself did not have a CLA, what "direct
contributions" would you (Microsoft, not you personally) not be able/willing
to make that you would be able/willing to make if it were? And is it able or
willing?
I think that's the question many people still don't have a clear answer to
(from any DB vendor, at least that I've seen).
--
Larry Garfield AIM: LOLG42
larry@garfieldtech.com ICQ: 6817012
"If nature has made any one thing less susceptible than all others of
exclusive property, it is the action of the thinking power called an idea,
which an individual may exclusively possess as long as he keeps it to
himself; but the moment it is divulged, it forces itself into the possession
of every one, and the receiver cannot dispossess himself of it." -- Thomas
Jefferson
Hello David,
Wednesday, February 27, 2008, 9:27:16 PM, you wrote:
Greetings, PDO community! My name is David Sceppa and I am a program
manager working at Microsoft on improving SQL Server for PHP data hosting.
Let me first just say that Microsoft is very interested in participating
in the PDO 2 effort and I plan to actively engage in the discussions of
the spec and the core via the mailing list. As a relative newcomer to
this space, Microsoft is highly incented to see a single solution that
serves the needs of this community. This is both from the standpoint of
technical investment (i.e. we would like to focus our resources on
delivering one rock solid answer rather than many across the space), and
for customer clarity as having too many choices often winds up being
confusing. We believe that PDO 2 is that solution going forward in the
PHP space, and we are therefore committed to seeing it through to fruition.
The approach that's been described in proposals (vendor-built drivers can
be covered via CLAs while the core components remain CLA-free) is
something I believe to be in the best interests of both driver writers and
the developers who use PDO. We would prefer to have the spec and the core
covered by CLA, so that we can make more direct contributions, yet we
understand that the community wishes to keep the spec and the core CLA-free.
Microsoft has a great deal of experience and lessons learned (both
positive and negative) through the evolution of ODBC and other data access
technologies that give us a unique perspective and we look forward to
contributing to the PDO 2 effort. I look forward to diving into more
technical discussions on the mailing list on issues such as whether or not
there should be a set of core PDO libraries, the PDO metadata vocabulary, driver extensibility, etc.
Thanks fro writing and welcome to the list. We appreciate your will to help
as much as we agree any other help. As you probably have noted already we
are a bit unsure how to preceed from now. Maybe you can start helping with
working on the current PDO. This would allow us to see some input from your
side that way introducing yourself and your team better. And it also allows
you to understand the way PHP gets developed better.
Best regards,
Marcus
Hello David,
Wednesday, February 27, 2008, 9:27:16 PM, you wrote:
Greetings, PDO community! My name is David Sceppa and I am a program
manager working at Microsoft on improving SQL Server for PHP data
hosting.
Thanks fro writing and welcome to the list. We appreciate your will
to help
as much as we agree any other help. As you probably have noted
already we
are a bit unsure how to preceed from now. Maybe you can start
helping with
working on the current PDO. This would allow us to see some input
from your
side that way introducing yourself and your team better. And it also
allows
you to understand the way PHP gets developed better.
I would also like to welcome you here. Is this the first time someone
has posted to a php.net mailinglist with an @microsoft.com address?
Anyways not requiring either the core or the spec to be under a CLA is
getting in the direction of where things can work out. Getting to know
you and some of the other developers is also another important step.
Other topic. Not sure if I have mentioned this, but has anyone
contacted Ingres yet. I am CC'ing Grant from Ingres who is maintaining
ext/ingres .. maybe he can shed some light ..
regards,
Lukas
Pierre Joye wrote:
You (as group)
We are individuals, all members of the mail lists.
Tell us the names of these entities, companies or persons, who are
going to contribute and what are actually their requirements.
The general list of data access providers has been given before and
isn't surprising.
I can't represent anyone other than myself in these discussions.
What will they bring (saying "expertise" is not something I can
buy)?
We bring development, maintenance, testing and documentation folk. We
bring in-depth data access knowledge. We bring previous experience
from working on standards. We bring experience from working on PHP.
A side benefit is that this leads to more people familiar with PHP code
and PHP processes. This grows the pool of talent with the potential
to contribute to PHP in general (as my management would like me to
do). The people are also able to help shape their future databases to
help the PHP user, for example, Oracle's Database Resident Connection
Pooling (DRCP).
Chris
--
Christopher Jones, Oracle
Email: christopher.jones@oracle.com Tel: +1 650 506 8630
Blog: http://blogs.oracle.com/opal/ Free PHP Book: http://tinyurl.com/f8jad
Pierre Joye wrote:
You (as group)
We are individuals, all members of the mail lists.
Ok, could the Microsoft and IBM people on this list please speak up
then? Could also one of the Oracle internals guys speak up on this
list? That is what Pierre was asking for.
regards,
Lukas
Lukas Kahwe Smith wrote:
Pierre Joye wrote:
You (as group)
We are individuals, all members of the mail lists.
Ok, could the Microsoft and IBM people on this list please speak up
then? Could also one of the Oracle internals guys speak up on this list?
That is what Pierre was asking for.
What do you want the Oracle internals guys to speak about? They may
not be known to you personally, but I've acknowledged some of the
coders in various bugs fixes, one of the driver architects has
featured in my blog, and some of the key people (including
"management") have attended the Zend Conferences here in California
for the last couple of years.
Chris
--
Christopher Jones, Oracle
Email: christopher.jones@oracle.com Tel: +1 650 506 8630
Blog: http://blogs.oracle.com/opal/ Free PHP Book: http://tinyurl.com/f8jad
Lukas Kahwe Smith wrote:
Pierre Joye wrote:
You (as group)
We are individuals, all members of the mail lists.
Ok, could the Microsoft and IBM people on this list please speak up
then? Could also one of the Oracle internals guys speak up on this
list?
That is what Pierre was asking for.What do you want the Oracle internals guys to speak about? They may
Mainly I want them to send patches and explain them. A simple hi
beforehand would be nice as well :)
regards,
Lukas
We change the rules all the time to fit the needs of PHP.
Do we?
This may not be one of those times, or this may not be the way to go, but I think
the concept of having better support from database companies is one
that at least deserves the benefit of a dialog.
Sure, that's what the "dialog" is - they asked if they could set their
own rules and we said "no".
That's what the discussion is - they've asked a question and got an answer.
We've discussed it long enough to be sure, and the answer is "NO".
Furthermore, I think Marcus has contributed enough to PHP that he does
not deserve to hear that what would be good for PHP is for him to "go
away."
Wait a second... "Somebody has contributed enough, so everybody should agree with him"?
Do I get it right?
I do respect Marcus (as well as everybody else, doesn't matter how big
his/her contribution is), but this doesn't matter I agree.
And I really do think that such an attempt to add a half-closed-source module into PHP
project MUST be rejected, as it violates all the rules and basically sets a new rule:
everybody can do anything he/she wants to do for no reason.
PDO opinions aside, I don't think any of us would actually
think that would put PHP in a more healthy situation.
Openness is healthy.
Adding new rules to make lawyers happy is not.
--
Wbr,
Antony Dovgal
We change the rules all the time to fit the needs of PHP.
Do we?
Sure. PHP 3 was dual licensed under the GPL. We introduced the Zend
License. We moved the PHP Manual under an Open Publication License,
which is not was it was originally licensed under. We introduced cvs
karma to restrict who could modify which parts of the code without
explicit permission from others.
And that's just about licensing and access to source commits.
We change technical things all the time. For example, when I started
using PHP, there were no OO concepts and register_globals was
On. Those changes to the essential nature of PHP also affect the
community and were done based on the needs of PHP.
Again, I am not saying we should change this here. I am just saying
that PHP has changed over the years. Like many projects, it becomes
more calcified over time, but there are changes.
This may not be one of those times, or this may not be the way to go, but I think
the concept of having better support from database companies is one
that at least deserves the benefit of a dialog.Sure, that's what the "dialog" is - they asked if they could set their
own rules and we said "no".That's what the discussion is - they've asked a question and got an
answer. We've discussed it long enough to be sure, and the answer
is "NO".
Based on my readings, I know where your position is, but I don't think
there is universal agreement on this. Heavens, we've spent more time
discussing the name of ifsetor, and I know that's not as important as
PDO in any aspect.
Furthermore, I think Marcus has contributed enough to PHP that he does
not deserve to hear that what would be good for PHP is for him to "go
away."Wait a second... "Somebody has contributed enough, so everybody
should agree with him"? Do I get it right?
I must have explain myself poorly, as you get it wrong. What I am
saying is that I felt your reply was rude because you told him that
because he presented a different opinion to you with respect to PDO
and a CLA, that it would be better off it he leaves PHP. That may not
be what you meant, but I don't think we should be telling people that
we want them to go.
What we should be telling people is that we think this is not the most
productive way to move PHP forward, which is what I would like to
presume is the goal of everyone in the conversation. We may differ on
how we should get there, but we would like to keep everyone involved
if possible.
And I really do think that such an attempt to add a
half-closed-source module into PHP project MUST be rejected, as it
violates all the rules and basically sets a new rule: everybody can
do anything he/she wants to do for no reason.
That's totally fine. I don't have problems with that. What I am saying
is that I have a problem with how you are saying this. This may be
cultural, or even personal, but I felt it was important to express my
opinion.
PDO opinions aside, I don't think any of us would actually
think that would put PHP in a more healthy situation.Openness is healthy.
Adding new rules to make lawyers happy is not.
We have rules to make lawyers happy already -- we call this the PHP
License. You just happen to like those rules.
We could bring in RMS and he could tell that that your rules are evil,
just as you feel that a CLA is evil. (I know I am putting words in
people's mouths here, forgive me.)
So, we're not discussing whether we should have rules to make lawyers
happy, we're discussing which rules we should have, and whether the
rules we currently use and the best rules for going forward.
Again, I am not saying whether we should or should not have a CLA for
PDO, and where PDO should live. I have an opinion, but, frankly, that
is not what I am trying to comment on here.
What I am trying to do is keep the level of the dialog on a
constructive basis.
-adam
--
adam@trachtenberg.com | http://www.trachtenberg.com
author of o'reilly's "upgrading to php 5" and "php cookbook"
avoid the holiday rush, buy your copies today!
If there is no CLA, will that mean we will not get the PDO 2 drivers
we need to be able to communicate with the databases?
Could, for example, MySQL say without a CLA we are not contributing code?
If so, what is the alternatives? Wait until we have some hacked up
version from someone not on the inside track?
Its a shame that their is not a legal understanding of the spirit of
the law, rather than just the letter of the law.
If their is no CLA, what are the alternatives?
--
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"
Hi,
If there is no CLA, will that mean we will not get the PDO 2 drivers
we need to be able to communicate with the databases?
It would be really nice if the pro CLA camp stops to condition the
existence of PDO (or its future) to the CLA acceptation. That's simply
wrong. Oracle, IBM and MySql (which states their point already, they
will accept the choice made by the php project) contribute already to
php.
The question is actually:
Can they continue to ignore PHP or do they have to have their
respective products working smoothly with PHP?
The answer is pretty obvious and we see announces on a regular basis
to proove they have to support PHP. Read the respective interviews or
stories about PHP, the tone is completely different now than a year
ago.
--
Pierre
http://blog.thepimp.net | http://www.libgd.org
Pierre, since you choose to ignore the mails I sent to your "secret" address,
I'm taking this to the list, maybe this will be noticed: Pay what you owe me!
--Jani
Pierre Joye kirjoitti:
Hi,
If there is no CLA, will that mean we will not get the PDO 2 drivers
we need to be able to communicate with the databases?It would be really nice if the pro CLA camp stops to condition the
existence of PDO (or its future) to the CLA acceptation. That's simply
wrong. Oracle, IBM and MySql (which states their point already, they
will accept the choice made by the php project) contribute already to
php.The question is actually:
Can they continue to ignore PHP or do they have to have their
respective products working smoothly with PHP?The answer is pretty obvious and we see announces on a regular basis
to proove they have to support PHP. Read the respective interviews or
stories about PHP, the tone is completely different now than a year
ago.
- Develop a PECL CLA that can optionally be used for PECL projects.
- If necessary, adapt the PHP License, so that it works nicely
together with the CLA.- The projects that want a CLA can choose between the PHP License or
LGPL.- Change the PELC web site so that projects can opt-in to using the
CLA.- Arrange it so that projects cannot drop the CLA flag.
- Add a user/CLA/project table to the PHP user database, and use this
in CVS ACLs.- Create a new CVS module php-default.
- Move all extensions that can be disabled and are not required for
others to PECL.- Link everything under php-src plus a default selection of
extensions to php-default.- Let us once and for all ban CLAs from php-src aka PHP core.
- Start developing PDO as part of CVS module php-src.
Sorry for not writing this earlier. So how does this idea sound?
Not terrible good actually. ALl the things that mention a CLA should
never come close to PHP or PECL in my opinion. If people want to develop
non-open software they can use their own resources for it.
regards,
Derick