On Wed, Aug 28, 2013 at 8:50 PM, Stas Malyshev <smalys...@sugarcrm.com> wrote: > 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,
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
