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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
