OK, so I just put in 140-something module updates... manually, grumble. I
(hopefully) avoided anything in core, whether that be PHP 4 or 5 - the way
we version core modules is going to need much more thought.
Apart from those, here's a list of the PECL extensions I can't or won't
touch. It seems that the CLA I hadn't spotted in pecl/sam was the only
reason I couldn't commit all 5000+ lines in a single shot back there, so I'm
a little bitter about these right now:
daffodildb (proprietary license)
ibm_db2 (IBM extension)
muscat (GPL'd)
mqseries (JAWA Management Software GmbH???)
pdo_ibm (IBM extension)
pdo_ids (IBM extension)
pdo_informix (IBM extension)
sam (CLA'd)
sdo (CLA'd IBM extension)
smbc (GPL'd)
tclink (LGPL'd)
I should probably not have worried about dealing with tclink... but I've
very little idea where I stand with the rest, apart from the CLA'd and
proprietary ones obviously.
- Steph
ps Can someone please create a 'siberia' module in CVS so we have somewhere
to bury genuinely dead PECL extensions?
Hello Steph,
Monday, March 31, 2008, 1:02:46 PM, you wrote:
OK, so I just put in 140-something module updates... manually, grumble. I
(hopefully) avoided anything in core, whether that be PHP 4 or 5 - the way
we version core modules is going to need much more thought.
Apart from those, here's a list of the PECL extensions I can't or won't
touch. It seems that the CLA I hadn't spotted in pecl/sam was the only
reason I couldn't commit all 5000+ lines in a single shot back there, so I'm
a little bitter about these right now:
daffodildb (proprietary license)
ibm_db2 (IBM extension)
muscat (GPL'd)
mqseries (JAWA Management Software GmbH???)
pdo_ibm (IBM extension)
pdo_ids (IBM extension)
pdo_informix (IBM extension)
sam (CLA'd)
sdo (CLA'd IBM extension)
smbc (GPL'd)
tclink (LGPL'd)
Did we not disallow GPL'd extensions in PECL?
If not can we finally require OSI approved licenses only and disallow
proprietary and GPL specifically?
Best regards,
Marcus
Hi Marcus, boy you're everywhere at once...
Did we not disallow GPL'd extensions in PECL?
If not can we finally require OSI approved licenses only and disallow
proprietary and GPL specifically?
Update: I've written to the authors of both the GPL'd extensions and
daffodildb (proprietary license) today.
- We can lose pecl/smbc to the attic, with the author's blessing.
- I didn't have a response yet regarding pecl/muscat, but it's been
superceded by another GPL'd extension which is sited elswhere (Xapian). So I
guess we're clear there too, I'd just rather have it from the horse's mouth. - The Daffodil folk are holding a meeting about theirs and will come back
to us with their plans after next week.
- Steph
Best regards,
Marcus
- I didn't have a response yet regarding pecl/muscat, but it's been
superceded by another GPL'd extension which is sited elswhere
(Xapian). So I guess we're clear there too, I'd just rather have it
from the horse's mouth.
Recently the pecl/muscat documentation was removed from phpdoc CVS. No
horse mouth was involved, but it seemed like a good time.
Regards,
Philip
Hi Philip,
Recently the pecl/muscat documentation was removed from phpdoc CVS. No
horse mouth was involved, but it seemed like a good time.
Just recording this to eliminate the bus factor. For the 'dead extensions'
page in the manual:
The replacement for the PHP interface to the muscat search engine is
available from http://www.xapian.org/download.php (in xapian-bindings).
Xapian is listed/linked in the 'real' current PHP manual - the one everybody
uses as opposed to the one under development - as the replacement for
muscat.
There's no known replacement for SMBC.
- Steph
Regards,
Philip
Did we not disallow GPL'd extensions in PECL?
I though so.
If not can we finally require OSI approved licenses only and disallow
proprietary and GPL specifically?
+1
Olivier
Hi Marcus,
Did we not disallow GPL'd extensions in PECL?
We do.
If not can we finally require OSI approved licenses only and disallow
proprietary and GPL specifically?
We do as well:
http://pecl.php.net/account-request.php (from the link on the home
page "I want to publish my PHP Extension in PECL".
ps: keep pecl-dev to the CC.... it is really a pecl discussion.
Cheers,
Hi Pierre,
Did we not disallow GPL'd extensions in PECL?
We do.
At least one of those extensions was originally moved out of the PHP core
into PECL because it was GPL'd. We're mixing old extensions and new rules
here, which is one very good reason to write to the extension authors
concerned prior to 'atticking' anything at all!
Anyway this is all noise now, I just hope to hear from the author of the
final GPL'd extension so we can finally call it a 100% rule.
- Steph
Hi Pierre,
Did we not disallow GPL'd extensions in PECL?
We do.
At least one of those extensions was originally moved out of the PHP core
into PECL because it was GPL'd. We're mixing old extensions and new rules
here, which is one very good reason to write to the extension authors
concerned prior to 'atticking' anything at all!Anyway this is all noise now, I just hope to hear from the author of the
final GPL'd extension so we can finally call it a 100% rule.
No need to wait, if the code is under GPL and still there, it must be
moved out from CVS (both never had a pecl release so it is half of an
issue). Let say we can move it as soon as the siberia top level module
is in place.
Cheers,
Hi all,
No need to wait, if the code is under GPL and still there, it must be
moved out from CVS (both never had a pecl release so it is half of an
issue). Let say we can move it as soon as the siberia top level module
is in place.
OK, I heard from the muscat author. Both GPL'd extensions can be disappeared
now. Daffodil's still on hold pending the outcome of a meeting.
So - plain old CVS attic or 'siberia' for the GPL'd ones?
- Steph
Hello Steph,
Tuesday, April 1, 2008, 2:50:51 PM, you wrote:
Hi all,
No need to wait, if the code is under GPL and still there, it must be
moved out from CVS (both never had a pecl release so it is half of an
issue). Let say we can move it as soon as the siberia top level module
is in place.
OK, I heard from the muscat author. Both GPL'd extensions can be disappeared
now. Daffodil's still on hold pending the outcome of a meeting.
So - plain old CVS attic or 'siberia' for the GPL'd ones?
IMO Attic.
Best regards,
Marcus
So - plain old CVS attic or 'siberia' for the GPL'd ones?
IMO Attic.
Yep, attic should be fine.
--
Wbr,
Antony Dovgal
So - plain old CVS attic or 'siberia' for the GPL'd ones?
IMO Attic.
Yep, attic should be fine.
I agree with you both (consider it done).
We'll need siberia for modules that have the potential to live again - these
two aren't in that category.
- Steph
So - plain old CVS attic or 'siberia' for the GPL'd ones?
IMO Attic.
Yep, attic should be fine.
I agree with you both (consider it done).
We'll need siberia for modules that have the potential to live again - these
two aren't in that category.
Siberia was meant for dead module with no potential to come back to
live. I can't see how these two can live again as they are under GPL,
unless the original authors agree to relicense them.
The unmaintained packages (which can be maintained again, aka back to
live) has be marked as such.
That reminds me that I have to update the RFC according to our discussions :P
Cheers,
Siberia was meant for dead module with no potential to come back to
live.
Not in my eyes. There's only a problem with CVS Attic if you want to bring
something back to life, so if there's no potential for that - why not use
it?
I can't see how these two can live again as they are under GPL,
unless the original authors agree to relicense them.
Not happening. a) both extensions wrap/interface GPL'd libraries and b) the
muscat library no longer exists.
The unmaintained packages (which can be maintained again, aka back to
live) has be marked as such.
Yes, we need to mark them ORPHANED. But that's a whole different story,
because we need to have some criteria about when a module becomes orphaned -
and we don't have that in place yet.
That reminds me that I have to update the RFC according to our discussions
:P
I'd call the 'PECL versioning' one a done deal at this stage, pretty much -
it just needs a write-up on pecl.php.net for newcomers to refer to, and a
request for the final handful of extensions to comply.
We probably need a whole new RFC for core module versioning. Want to kick it
off?
- Steph
Siberia was meant for dead module with no potential to come back to
live.Not in my eyes. There's only a problem with CVS Attic if you want to bring
something back to life, so if there's no potential for that - why not use
it?
Some archive:
http://news.php.net/php.pecl.dev/5283 (and the other posts around it).
and about Attic, the idea behind a graveyard was about leaving the
code around for study purposes.
I can't see how these two can live again as they are under GPL,
unless the original authors agree to relicense them.Not happening. a) both extensions wrap/interface GPL'd libraries and b) the
muscat library no longer exists.
So they are dead cows.
That reminds me that I have to update the RFC according to our discussions
:PI'd call the 'PECL versioning' one a done deal at this stage, pretty much -
it just needs a write-up on pecl.php.net for newcomers to refer to, and a
request for the final handful of extensions to comply.
Filling a bug may be enough.
We probably need a whole new RFC for core module versioning. Want to kick it
off?
I would not like to have different docs explaining the same thing It
will be very confusing. We already covered almost every problem for
core or pecl extensions. Let make it clean and readable and then see
how it can be improved.
Cheers,
Hi Pierre,
and about Attic, the idea behind a graveyard was about leaving the
code around for study purposes.
Code in the attic can be read online but can't be checked out, so I take
your point about 'study purposes'. I'd use siberia for things like axis2,
where the project is live and hosted elsewhere but the original code is
still in PECL. Or classkit, which was superceded by runkit but which still
works. Marcus' demoext could go into siberia too - it's literally just a
demo and may be useful to some, but it shouldn't really be part of a PECL
checkout.
I'd call the 'PECL versioning' one a done deal at this stage, pretty
much -
it just needs a write-up on pecl.php.net for newcomers to refer to, and
a
request for the final handful of extensions to comply.Filling a bug may be enough.
Nah, I'll do the polite thing and send out emails today. We can file bugs
when people don't comply after the request (and after we have something
with clear rules we can link to!).
We probably need a whole new RFC for core module versioning. Want to
kick it
off?I would not like to have different docs explaining the same thing It
will be very confusing. We already covered almost every problem for
core or pecl extensions.
I thought that at first too, but Christopher Jones faced me off-list with
some scenarios I hadn't considered. It's more complex than we'd allowed
because a single PECL extension can be symlinked to more than one PHP
branch - we need to look into this more.
Let make it clean and readable and then see
how it can be improved.
OK, but I need to spend some time on 'real work', so can I leave this with
you for now?
- Steph
Hi Steph,
Hi Pierre,
and about Attic, the idea behind a graveyard was about leaving the
code around for study purposes.Code in the attic can be read online but can't be checked out, so I take
your point about 'study purposes'. I'd use siberia for things like axis2,
where the project is live and hosted elsewhere but the original code is
still in PECL. Or classkit, which was superceded by runkit but which still
works.
All of them belong to siberia, just like the gpl'ed dead cows. KISS.
Marcus' demoext could go into siberia too - it's literally just a
demo and may be useful to some, but it shouldn't really be part of a PECL
checkout.
I strongly disagree, the demoext must remain in PECL and can even have
releases. The main goal (and to be honest, fantastic goal) is to teach
how to write a PHP extension. How can we relegate it to siberia?
I'd call the 'PECL versioning' one a done deal at this stage, pretty
much -
it just needs a write-up on pecl.php.net for newcomers to refer to, and
a
request for the final handful of extensions to comply.Filling a bug may be enough.
Nah, I'll do the polite thing and send out emails today. We can file bugs
when people don't comply after the request (and after we have something
with clear rules we can link to!).
There is nothing not polite to report bugs. It is even the first form
of OS contribution.
We probably need a whole new RFC for core module versioning. Want to
kick it
off?I would not like to have different docs explaining the same thing It
will be very confusing. We already covered almost every problem for
core or pecl extensions.I thought that at first too, but Christopher Jones faced me off-list with
some scenarios I hadn't considered. It's more complex than we'd allowed
because a single PECL extension can be symlinked to more than one PHP
branch - we need to look into this more.
Indeed, we discussed these cases too and I pointed your attention many
times to the complexity of this situation. That does not change my
thoughts: one goal (covering many cases), one RFC, one doc.
Let make it clean and readable and then see
how it can be improved.OK, but I need to spend some time on 'real work', so can I leave this with
you for now?
What I like in communication based on mails is that they are
asynchronous (or should be ;)