On Sun, Dec 22, 2024, at 9:23 AM, Jakub Zelenka wrote: > On Mon, Dec 16, 2024 at 9:05 PM Christoph M. Becker <cmbecke...@gmx.de> wrote: >> On 16.12.2024 at 14:18, Jakub Zelenka wrote: >> > There was a suggestion of RFC but that might be a bit too much as it's just >> > an internal change / addition. But certainly some overview on internals >> > should be done so writing this instead. >> >> I'm fine with not going through the RFC process, although the policy[1] >> police might come after us. :) >> > > I think it fits to all inclusion criteria and doesn't go against any > exclusion. Maybe except that "de facto standard" but for our use there > was really no other option as I mentioned in my comparison so it was > the only library left for our needs if there is only one, then it's "de > facto standard" we could say. > > Btw. It was probably mistake to set that policy for C code because we > don't really need to care if PHP recommends any tool there - I > completely missed it when voting for it. This should be just for PHP > application that we care about. We should modify that policy > accordingly - I need to make a list of changes that to the policies as > there are quite a few points. > > Regards, > > Jakub
Point of order: The recently adopted 3rd party code policy does not apply to C tooling. It mentions "PHP Tooling", which is defined as "PHP code run by PHP.net". The website, docs tooling, etc. It has no bearing on what C libraries or toolchains can or should be used in php-src itself. (Whether that's unit testing, url parsers, HTML parsers, threading libraries, etc.) I have no opinion or experience on C testing frameworks, other than "yes, tests please!" :-) --Larry Garfield
