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
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:
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
Best regards,
Marcus
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
Hi,
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.
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
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,
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.
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
Best regards,
Marcus
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
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:
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
Best regards,
Marcus
-----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
- Markus
iD8DBQFHpXWp1nS0RcInK9ARAnBZAJ928I83vNN23bhkXZ82mowy6VuV9QCeI3Q5
oQ98shWUEDyOoyC3GgR+8YM=
=uquW
-----END PGP SIGNATURE
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
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
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,
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
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.)
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
Moin Lukas,
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?
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
Moin Lukas,
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?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
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)
Ah sorry - I'm not good with multi-tasking, mixed up two ongoing
conversations here.
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?
I don't have concerns about a PECLA module utilizing the existing PECL
infrastructure in any way. Do you?
- Steph
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?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
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:
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
Best regards,
Marcus
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" helly@php.net
To: "Steph Fox" steph@zend.com
Cc: pdo@lists.php.net; "internals" internals@lists.php.net
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:
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
Best regards,
Marcus