Hi! > There are two extensions that I'm aware of where we have strong > technical grounds to remove them, that's wddx (for reasons of security > and questionable utility) and interbase (has a major bug since the PHP 7 > migration and there is nobody with knowledge of this exotic DB driver to > fix it).
I mostly agree, but this RFC is not for discussing specific extensions, it's for establishing the policy of what we do with such extensions, and how. > like gettext, readline and ftp on that list). Extensions without > official maintainer in php-src tend to be passively maintained, e.g. I Or not. As is the case with several of them. > years (and of course, small extensions like gettext just don't get many > changes over time). Moving an extension to PECL effectively makes it > completely unmaintained. I think if it doesn't have official maintainer and nobody touched it for years, it's completely unmaintained right now. But for cases like this, the RFC says: Option: for some extensions, which are clearly needed but nobody stepped up in person to claim maintainership, we can have designated “community maintained” status, which would mean PHP developers as a group have shared responsibility for this extension. > > To me, moving extensions to PECL is a Pretty Big Deal. It's something > that should be done on a case-by-case basis, possibly with an RFC, not > something that happens based on a blanket policy. I do not see any contradiction between this and what RFC says. In fact, RFC specifically says: In case there are objections to moving unmaintained extension to PECL, separate RFC vote can be held about the move, initiated by the RMs of the current release or any interested party. The decision can be taken for each extension individually. So what exactly you don't like here? It's pretty much exactly the opposite of "blanket policy". I am sorry if I am missing something, but it looks to me like you're saying "I don't like this, we should do this instead" and then literally you are saying exactly what the RFC is saying. Where is the problem? -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
