Hi,
I would like to react on Stat's "it's-not-our-problem" comment in
https://bugs.php.net/bug.php?id=63520
I am very sad to see a core developer take such a passive-aggressive stance
against distributions' problems. My wild guess would be that most of the
users use the PHP in the pre-packaged form. Thus we really need to work
together and not fight against each other even though the set of the
problems (and their solutions) each party solves is different.
Pierre did a very good job at approaching Debian and helping us with
external libgd library, and it helped a lot a both parties.
So I just ask you, please reconsider next time when you want to post
similar comment and consider the ecosystem around the PHP in your decisions.
Ondrej
Ondřej Surý ondrej@sury.org
Have you tried Knot DNS – https://www.knot-dns.cz/
– a high-performance authoritative-only DNS server
Hi,
I would like to react on Stat's "it's-not-our-problem" comment in
https://bugs.php.net/bug.php?id=63520
I see Stas' reply as respond to Jordi (seld on php.net). We can discuss
what we will do, but for arguing about Debian/Ubuntu current
packaging decisions it is the wrong place. This has to be discussed in
those communities. Those topics are related but still separate topics,
decided by different groups.
johannes
Hi!
I would like to react on Stat's "it's-not-our-problem" comment in
https://bugs.php.net/bug.php?id=63520
I assume by "Stat" you mean myself, though I'm not the only one who
expressed the same sentiment of questioning why this is submitted as a
"bug" in PHP. Assuming that, below are my thoughts on the subject (I
apologize in advance for the length).
I am very sad to see a core developer take such a passive-aggressive stance
against distributions' problems. My wild guess would be that most of the
users use the PHP in the pre-packaged form. Thus we really need to work
together and not fight against each other even though the set of the
problems (and their solutions) each party solves is different.
I assure you that by raising this question I meant no aggression or
animosity toward anybody, but I do have a question of priorities here. I
understand that Debian has certain ideological guidelines which preclude
them from distributing certain software that does not fit their views on
how software should be licensed. Even though as far as I know Debian has
"non-free" area in which they distribute software with licenses other
than approved by Debian's guidelines, but ultimately I recognize that
the decision of what to distribute and what not is Debian's and their
alone. However, what happens in PHP project is decided by PHP developers
community and should gain consensus and acceptance in the community.
However, given all that, I think the matter would be handled better if,
before taking decisions that can influence many users of PHP that chose
to trust Debian to deliver their PHP builds, Debian would consult with
PHP community on how to handle that. I do not remember this question
being raised on PHP list and discussed there. I personally found about
this decision by reading panic posts in the blogs along the line of "PHP
removes JSON support", which I do not think is the best outcome we could
hope for. I think PHP bug database is neither appropriate nor suitable
forum for discussing such things - it is meant for tracking bugs in PHP
code, e.g. mistakes made while implementing certain functionalities, and
the license of JSON code, which obviously being controversial and
causing issues for Debian, is definitely not there by any mistake and
should not be treated as "bug". It should be treated as licensing issue
and as such raised on this list and discussed and handled appropriately.
I certainly and wholeheartedly agree that we do need to work together
with distributions and that it would benefit our users. As a good start,
I would ask Debian representatives to work with PHP community within
processes accepted by the community, i.e. explain on this list why it is
impossible to distribute PHP the way it was distributed before for
years, why it is impossible to fit this code withing any "non-free"
framework Debian has, what Debian suggests to do (taking into account
this will influence wider PHP users community, many of whom, however
regrettable may it be, do not use Debian) and so on, initiating the
discussion that hopefully would come to some conclusion that would be
satisfactory to everyone involved.
Thanks,
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
On Wed, Aug 28, 2013 at 9:50 PM, Stas Malyshev smalyshev@sugarcrm.comwrote:
Hi!
I would like to react on Stat's "it's-not-our-problem" comment in
https://bugs.php.net/bug.php?id=63520However, given all that, I think the matter would be handled better if,
before taking decisions that can influence many users of PHP that chose
to trust Debian to deliver their PHP builds, Debian would consult with
PHP community on how to handle that. I do not remember this question
being raised on PHP list and discussed there.
http://marc.info/?l=php-internals&m=136768085009866&w=2
Kaplan
Hi!
This is great but this is not exactly what I'm talking about. There's a
big difference between having an extension that does JSON in PECL and
replacing part of PHP core (and very commonly used part) by something
else. It very well may be that Remi's extension is ways better that
standard one, and it would be a big step forward for PHP to start using
it instead of what we have now. But it should be an explicit decision
reached by consensus of PHP community, through RFC process, discussion,
vote and so on.
Now, as I said, Debian can choose what they distribute, including
unilaterally. But we can't both say it's Debian's decision alone and
that PHP devs should consider it a PHP issue - if it's a PHP issue, than
the decision to replace core extension (and not the decision to create
PECL extension, which has much less impact and has the consensus almost
always implied - who would object against having a PECL extension that
does something useful?) should be explicitly taken by PHP community. So
if you think it is a PHP issue - please create an RFC with the arguments
to that effect, let's get it discussed and reviewed and have it treated
as PHP issues should be treated.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
On Wed, Aug 28, 2013 at 10:45 PM, Stas Malyshev smalyshev@sugarcrm.comwrote:
Hi!
This is great but this is not exactly what I'm talking about. There's a
big difference between having an extension that does JSON in PECL and
replacing part of PHP core (and very commonly used part) by something
else.
Well, having the new implementation in PECL is a logical step to publish
the code and let people test it.
His mail offers (my emphasis):
1/ update existing pecl/json extension
- on pecl for older PHP 5.3 - 5.5
- on php-src in master / 5.6 *
And while the issue was first reported by Debian, the other distributions
share the same concerns. This is why PHP should consider this - because the
other parts of the eco-system are already going forward with this.
I agree to what you said about a bug not being a discussion. But it was the
first try to communicate with the community. Today, I would raise the issue
differently, but Remi's mail with the subject of "Proposal: new
implementation of JSON extension" should have been a good start.
Kaplan
Hi!
And while the issue was first reported by Debian, the other
distributions share the same concerns. This is why PHP should consider
this - because the other parts of the eco-system are already going
forward with this.
What we need to consider this extension as a replacement for core JSON is:
- explanation of advantages and disadvantages (noting that for most PHP
users "weird license" is not a significant disadvantage of the
extension) of the change - RFC
- API description
- potential BC problems
- performance impact
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Stas Malyshev in php.internals (Wed, 28 Aug 2013 14:40:06 -0700):
What we need to consider this extension as a replacement for core JSON is:
- explanation of advantages and disadvantages (noting that for most PHP
users "weird license" is not a significant disadvantage of the
extension) of the change- RFC
- API description
- potential BC problems
- performance impact
Some PECL extensions rely on (static?) json: couchdb, couchbase and
solr. The maintainers of these extensions will have some work to do,
unless the replacement is completely BC.
Jan
Le 29/08/2013 00:36, Jan Ehrhardt a écrit :
Stas Malyshev in php.internals (Wed, 28 Aug 2013 14:40:06 -0700):
What we need to consider this extension as a replacement for core JSON is:
- explanation of advantages and disadvantages (noting that for most PHP
users "weird license" is not a significant disadvantage of the
extension) of the change- RFC
- API description
- potential BC problems
- performance impact
Some PECL extensions rely on (static?) json: couchdb, couchbase and
solr. The maintainers of these extensions will have some work to do,
unless the replacement is completely BC.
Fedora used to build json extension as shared (like most extension).
We never encounter any issue with other extension (except load order,
but this is a well known and managed thing)
jsonc is really a dropin replacement.
- for other extension, same API/ABI
- for userland
Remi.
Jan
Le 28/08/2013 23:40, Stas Malyshev a écrit :
Hi!
And while the issue was first reported by Debian, the other
distributions share the same concerns. This is why PHP should consider
this - because the other parts of the eco-system are already going
forward with this.
Yes. This is not a Debian only problem.
Most of linux distribution are affected (Fedora, Mandriva, Mageia,
OpenSuse, Ubuntu...)
AFAIK no one have altered PHP.
We only build with --disable-json which is available in the standard
build process, and build/ship jsonc separately.
There is also a consensus to move on this "only" for new PHP 5.5 and
keep json in PHP 5.3 / 5.4 as this problem was not discovered before.
What we need to consider this extension as a replacement for core JSON is:
- explanation of advantages and disadvantages (noting that for most PHP
users "weird license" is not a significant disadvantage of the
extension) of the change
Yes, most PHP users don't care of License.
especially those who want to do "evil" ;)
But we are PHP project members. And we ship an OpenSource software which
is Licensed under the "PHP License", a "really" free License (per FSF
definition).
So, of course, we expect users to respect this License.
And probably, we'd like them to respect OpenSource, so we need to have
an exemplary conduct about those License issues.
- RFC
- API description
- potential BC problems
- performance impact
Already drafted : https://wiki.php.net/rfc/free-json-parser
I was thinking to submit this for discussion later (mostly because I
will be AFK first week of september), but as the discussion raised now...
Remi.
hi Remi!
But we are PHP project members. And we ship an OpenSource software which
is Licensed under the "PHP License", a "really" free License (per FSF
definition).
Ah? I always read that the PHP License is not actually Free as per FSF
definition, and not compatible with their true free license (GPL). Did
that change recently? :)
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
Le 29/08/2013 07:54, Pierre Joye a écrit :
hi Remi!
But we are PHP project members. And we ship an OpenSource software which
is Licensed under the "PHP License", a "really" free License (per FSF
definition).Ah? I always read that the PHP License is not actually Free as per FSF
definition, and not compatible with their true free license (GPL). Did
that change recently? :)
This is not a problem of GPL definition.
From FSF web site:
"The following licenses [...which included the PHP one ...] are free
software licenses, but are not compatible with the GNU GPL."
And of course, only the first part is important here.
So most linux distribution recognize PHP License as a free License.
Remi.
Cheers,
2013/8/28 Stas Malyshev smalyshev@sugarcrm.com:
Hi!
And while the issue was first reported by Debian, the other
distributions share the same concerns. This is why PHP should consider
this - because the other parts of the eco-system are already going
forward with this.What we need to consider this extension as a replacement for core JSON is:
- explanation of advantages and disadvantages (noting that for most PHP
users "weird license" is not a significant disadvantage of the
extension) of the change- RFC
- API description
- potential BC problems
- performance impact
- and resources! (Maybe a Debian guy that cares a lot about this could
help? Because that's the biggest issue, most of the time.)
Hi!
I would like to react on Stat's "it's-not-our-problem" comment in
https://bugs.php.net/bug.php?id=63520I assume by "Stat" you mean myself,
Change your first name! It is incompatible with most autocomplete out there ;-)
I am very sad to see a core developer take such a passive-aggressive stance
against distributions' problems. My wild guess would be that most of the
users use the PHP in the pre-packaged form. Thus we really need to work
together and not fight against each other even though the set of the
problems (and their solutions) each party solves is different.I assure you that by raising this question I meant no aggression or
animosity toward anybody,
I support your comment, even if I disagree with his conclusion, I
never (or rarely ;) saw aggressive comments from Stas but sometimes
expressing opinion in a diplomatic way without hearting everyone
feeling is alsmot impossible in technical (or half technical here)
topics.
but I do have a question of priorities here. I
understand that Debian has certain ideological guidelines which preclude
It is important to keep in mind that not only Debian is concerned
about this problem, other distributions have the same issue with this
module, it has been brought to our attention many times in the past,
via the bug tracker or on this list. It is also the main reason why
Remi began to work on an alternative implementation. While being at it
he also added some neat new features.
them from distributing certain software that does not fit their views on
how software should be licensed. Even though as far as I know Debian has
"non-free" area in which they distribute software with licenses other
than approved by Debian's guidelines, but ultimately I recognize that
the decision of what to distribute and what not is Debian's and their
alone. However, what happens in PHP project is decided by PHP developers
community and should gain consensus and acceptance in the community.
agreed.
However, given all that, I think the matter would be handled better if,
before taking decisions that can influence many users of PHP that chose
to trust Debian to deliver their PHP builds, Debian would consult with
PHP community on how to handle that. I do not remember this question
being raised on PHP list and discussed there. I personally found about
this decision by reading panic posts in the blogs along the line of "PHP
removes JSON support", which I do not think is the best outcome we could
hope for. I think PHP bug database is neither appropriate nor suitable
forum for discussing such things - it is meant for tracking bugs in PHP
code, e.g. mistakes made while implementing certain functionalities, and
the license of JSON code, which obviously being controversial and
causing issues for Debian, is definitely not there by any mistake and
should not be treated as "bug". It should be treated as licensing issue
and as such raised on this list and discussed and handled appropriately.
Right, but it is good to track issues, be technical, documentation
related or lack or wrong licenses, we had many, but minor, license
related bug reports.
I certainly and wholeheartedly agree that we do need to work together
with distributions and that it would benefit our users. As a good start,
I would ask Debian representatives to work with PHP community within
processes accepted by the community, i.e. explain on this list why it is
impossible to distribute PHP the way it was distributed before for
years, why it is impossible to fit this code withing any "non-free"
framework Debian has, what Debian suggests to do (taking into account
this will influence wider PHP users community, many of whom, however
regrettable may it be, do not use Debian) and so on, initiating the
discussion that hopefully would come to some conclusion that would be
satisfactory to everyone involved.
Remi will propose it via the standard process, that means a RFC draft,
discussions, votes, etc. He always wanted to do it this way.
Having it this new json extension in pecl is about getting more
feedback and catch any possible compatibility issues. After a while,
it will be proposed it as a dropin replacement for ext/json. Sadly the
FUD about PHP dropping json support, which began on a blog post from a
totally uninformed person (he corrected his post since), brought way
too much attention to this minor problem. However that's not something
we can control, welcome to the internet :).
That being said, I am all for a more deeper cooperation between
distributions and upstream projects. The more it happens, the less
differences we will have between a vanilla release and the packages
available in the major distributions. Many issues are understanding
issues, like suhoshin patches or other changes with high impacts at
the core level. That's what I did by inviting the distributions
security guys to our security team, for a 1st step. We need to do
more, in both directions, we can't simply ignore each other needs,
that will never work well.
By the way, readers should also, without animosity, take Stefan's
comment with a lot of salt. While he expresses his opinion in a
straight way, he does not necessary represent everyone's opinion, be
for the form or the conclusions. It is also confusing whether he is
active or not inside php.net, as he keeps coming and leaving us for
various reasons, mostly security related :).
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
On Wed, Aug 28, 2013 at 8:50 PM, Stas Malyshev smalyshev@sugarcrm.comwrote:
Hi!
I would like to react on Stat's "it's-not-our-problem" comment in
https://bugs.php.net/bug.php?id=63520I assume by "Stat" you mean myself, though I'm not the only one who
Yup, sorry for mangling your name, this must be a result of me installing
SPSS and analyzing some data in the same time :)
expressed the same sentiment of questioning why this is submitted as a
"bug" in PHP. Assuming that, below are my thoughts on the subject (I
apologize in advance for the length).I am very sad to see a core developer take such a passive-aggressive
stance
against distributions' problems. My wild guess would be that most of the
users use the PHP in the pre-packaged form. Thus we really need to work
together and not fight against each other even though the set of the
problems (and their solutions) each party solves is different.I assure you that by raising this question I meant no aggression or
animosity toward anybody, but I do have a question of priorities here.
Ok, point taken. Sorry for jumping to conclusions to early.
I understand that Debian has certain ideological guidelines which preclude
them from distributing certain software that does not fit their views on
how software should be licensed. Even though as far as I know Debian has
"non-free" area in which they distribute software with licenses other
than approved by Debian's guidelines, but ultimately I recognize that
the decision of what to distribute and what not is Debian's and their
alone. However, what happens in PHP project is decided by PHP developers
community and should gain consensus and acceptance in the community.
I would like to point out that it's not just the "Debian" (and other
distributions)
that has problem with JSON (non-free) license. If you look at the JSON
presentation (link is somewhere in the FUD article) you will see the JSON
author to mock IBM for giving them permission to use JSON for evil.
(Also note the motivation – he did it to contribute to War on Terror, and I
only
can wish that it was ment as a joke, but I am afraid it wasn't. But I can
never
understand this whole concept anyway...)
However, given all that, I think the matter would be handled better if,
before taking decisions that can influence many users of PHP that chose
to trust Debian to deliver their PHP builds, Debian would consult with
PHP community on how to handle that. I do not remember this question
being raised on PHP list and discussed there.
Unfortunatelly nobody pointed out that it has to be discussed in the mailing
list in the mentioned bug report. We have stated that we have a problem
with JSON license and we had to solve the problem we had.
I personally found about
this decision by reading panic posts in the blogs along the line of "PHP
removes JSON support", which I do not think is the best outcome we could
hope for.
I am sorry that it ended in a shitstorm by ignorant people, who are unable
to ask before they write bullshit, but I am not sure if we can prevent
that.
I think PHP bug database is neither appropriate nor suitable
forum for discussing such things - it is meant for tracking bugs in PHP
code, e.g. mistakes made while implementing certain functionalities, and
the license of JSON code, which obviously being controversial and
causing issues for Debian, is definitely not there by any mistake and
should not be treated as "bug". It should be treated as licensing issue
and as such raised on this list and discussed and handled appropriately.
I consider the licensing issue as a bug and it's always better to track it
as issue, but I get it that our views differ.
I certainly and wholeheartedly agree that we do need to work together
with distributions and that it would benefit our users. As a good start,
I would ask Debian representatives to work with PHP community within
processes accepted by the community, i.e. explain on this list why it is
impossible to distribute PHP the way it was distributed before for
years, why it is impossible to fit this code withing any "non-free"
framework Debian has, what Debian suggests to do (taking into account
this will influence wider PHP users community, many of whom, however
regrettable may it be, do not use Debian) and so on, initiating the
discussion that hopefully would come to some conclusion that would be
satisfactory to everyone involved.
The "non-free" part of the archive is only a last resort solution. When you
move something to non-free, you also need to move any package that
depends into a contrib part of the archive, and that would be much worse
than replacing embedded json extension with the pecl that Remi wrote.
Basically the "non-free" was created to circumvent the US crypto export
restrictions (the machine was hosted outside US) and not as a solution
to license problems in core packages created by a guy who thinks
it's funny to mess with people and mocks people who takes the licensing
seriously.
O.
Ondřej Surý ondrej@sury.org
Have you tried Knot DNS – https://www.knot-dns.cz/
– a high-performance authoritative-only DNS server
Hi!
Unfortunatelly nobody pointed out that it has to be discussed in the mailing
list in the mentioned bug report. We have stated that we have a problem
with JSON license and we had to solve the problem we had.
I consider the licensing issue as a bug and it's always better to track it
as issue, but I get it that our views differ.
Please don't misunderstand me, it's not a question of how important it
is and I don't question that it is very important for you. I'm just
saying if it's in the bug DB, most people won't see it, because bug db
has literally thousands of reports and next to nobody reads every one of
them and all the discussions there unless they are a) asked to by
somebody, b) maintain extensions against which the bug is filed or c)
performing community service by going through bug DB and looking for
things they could fix. Or they randomly notice the discussion on the
bugs list. But it is very easy to miss it, and the bug db is not made
for discussing issues - it is made for tracking and fixing them, and
people treat it accordingly. So if something is a question which needs
discussion, it is proper to raise it to the list, that doesn't mean
automatically it's considered not important or not worth fixing - quite
the contrary, raising it on the list makes sure more people are aware of
it and can participate in solving it.
The "non-free" part of the archive is only a last resort solution. When you
move something to non-free, you also need to move any package that
depends into a contrib part of the archive, and that would be much worse
than replacing embedded json extension with the pecl that Remi wrote.
Could you describe the reasons why it would be much worse? I.e. how the
user experience changes, what additional actions, if any, users would
have to do, etc.? I am asking this because right now as far as I can see
while json-c is in good shape, it has certain performance issues and
compatibility issues. I hope they would be fixed, but I think we need to
have all the options laid out before us to evaluate.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
On Thu, Aug 29, 2013 at 11:03 AM, Stas Malyshev smalyshev@sugarcrm.comwrote:
So if something is a question which needs
discussion, it is proper to raise it to the list, that doesn't mean
automatically it's considered not important or not worth fixing - quite
the contrary, raising it on the list makes sure more people are aware of
it and can participate in solving it.
Ok, point taken.
The "non-free" part of the archive is only a last resort solution. When
you
move something to non-free, you also need to move any package that
depends into a contrib part of the archive, and that would be much worse
than replacing embedded json extension with the pecl that Remi wrote.Could you describe the reasons why it would be much worse? I.e. how the
user experience changes, what additional actions, if any, users would
have to do, etc.?
Snippet from Debian Developers manual:
Packages which do not conform to the DFSG are placed in the non-free
section. These packages are not considered as part of the Debian
distribution, though we enable their use, and we provide infrastructure
(such as our bug-tracking system and mailing lists) for non-free software
packages.
Also non-free (and contrib) are not enabled by default (I think), so people
would have to modify their apt/sources.lists to enable the extra archive.
Any package depending on php5 would have to be moved to the contrib/
section (again not enabled by default), e.g. every packaged extension and
every packaged web app. That's simply not going to fly just because of JSON
extension. It could happen only if you have relicenced whole PHP under some
non-free license and were not willing to relicense it back (but I think in
this case somebody would fork PHP as it happened to some other big projects
before - f.e. XFree86 vs Xorg).
And I even don't want to imagine the scale of the fallout from such
transfer from main to non-free for PHP.
I am asking this because right now as far as I can see
while json-c is in good shape, it has certain performance issues and
compatibility issues. I hope they would be fixed, but I think we need to
have all the options laid out before us to evaluate.
Well, basically the pecl-json-c is now a default provider of JSON extension
in Debian (and Fedora) and the downstream distributions (Ubuntu, RHEL, ...).
And I don't even know if Fedora has similar place to put non-free packages.
O.
Ondřej Surý ondrej@sury.org
Have you tried Knot DNS – https://www.knot-dns.cz/
– a high-performance authoritative-only DNS server
Ondřej Surý wrote:
Well, basically the pecl-json-c is now a default provider of JSON extension
in Debian (and Fedora) and the downstream distributions (Ubuntu, RHEL, ...).
This is an area I've highlighted in the past ... While the PHP distributions
define a 'core' set of modules, I don't know of any Linux distribution that
actually duplicates it? I'm always having to check which 'modules' are loaded as
many of what is called 'core' are not loaded by default. And that does not even
get as far as adding pecl modules and in some cases how adding pear ones are
handled.
The system has been broken for a long time, and it is getting more and more
difficult to ensure that larger projects work 'out of the box'. Normally you
have to say 'x is not loaded', and then make a guess at how that can be fixed on
the particular distribution? And when ISP's are providing the PHP on shared
hosting it's flavoured by the Linux distribution defaults.
In the past I've asked for better support for the modular approach rather than
simply assuming everything 'core' is always compiled in. Handling this comes in
that category and while in this particular case it would be optimal that both
versions work identically, something is going to be broken or 'improved'?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk