Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » orphaned extensions in 7.1? »

orphaned extensions in 7.1?

php.internals

Stas Malyshev

10 years ago
Hi! I wonder if we shouldn't move orphaned extensions out of the core and in PECL in 7.1? If nobody maintains the code, should it really be part of the core? Right now we have two orphaned extensions - wddx and xmlrpc, I suspect both are not too widely used now. They also had some issues, and without maintainer they turn into a liability. Continuing on this topic, maybe we also should have a review of the rest of the extensions and check if the ones marked as maintained still are, and if current maintainers are not active anymore ask for new ones to be assigned or change their status accordingly? Would like to har what do you think on the matter,
-- Stas Malyshev smalyshev@gmail.com

Davey

10 years ago
The only negative I see for this is that it reinforces PECL as being Siberia. Having said that, it's better than deleting them, and they shouldn't be in core. - Davey On Sun, Jul 17, 2016 at 5:03 PM, Stanislav Malyshev <smalyshev@gmail.com> wrote:

Stas Malyshev

10 years ago
Hi!
> The only negative I see for this is that it reinforces PECL as being > Siberia. Having said that, it's better than deleting them, and they > shouldn't be in core.
Right. We want to keep them somewhere in case somebody wants to pick them up and use them or maintain them.
-- Stas Malyshev smalyshev@gmail.com

Cameron Ball

10 years ago
Hello internals, I work for Moodle (https://en.wikipedia.org/wiki/Moodle) We recently implemented an XML-RPC server using the XML-RPC extension. I actually found a bug in it and am working on a patch in my spare time. If there is a maintaner needed for the extension, I would be happy to volunteer. On 18 July 2016 at 08:44, Stanislav Malyshev <smalyshev@gmail.com> wrote:

Stas Malyshev

10 years ago
Hi!
> I work for Moodle (https://en.wikipedia.org/wiki/Moodle) > > We recently implemented an XML-RPC server using the XML-RPC extension. I > actually found a bug in it and am working on a patch in my spare time. > If there is a maintaner needed for the extension, I would be happy to > volunteer.
Great! The good start would be to start sending patches and then request PHP account.
-- Stas Malyshev smalyshev@gmail.com

Pierre Joye

10 years ago
hi, On Mon, Jul 18, 2016 at 7:12 AM, Davey Shafik <davey@php.net> wrote:
> The only negative I see for this is that it reinforces PECL as being > Siberia. Having said that, it's better than deleting them, and they > shouldn't be in core.
I see other, one of them is BC breaks. xmlrpc is used quite a lot still (limesurvey f.e. or moodle as this other reply confirmed), removing without previous warnings or not even trying to get a maintainer before moving it sounds a bit like a bad move to me. I never saw a project actually using wddx but I think we could see a similar situation (with less impacted users maybe). Cheers, Pierre

Niklas Keller

10 years ago
2016-07-18 9:54 GMT+02:00 Pierre Joye <pierre.php@gmail.com>:
> hi, > > On Mon, Jul 18, 2016 at 7:12 AM, Davey Shafik <davey@php.net> wrote: > > The only negative I see for this is that it reinforces PECL as being > > Siberia. Having said that, it's better than deleting them, and they > > shouldn't be in core. > > I see other, one of them is BC breaks. >
Moving extensions to PECL is allowed in x.y.z to x.y+1.z: Extensions support can be ended (moved to pecl) See: https://wiki.php.net/rfc/releaseprocess xmlrpc is used quite a lot still (limesurvey f.e. or moodle as this

Pierre Joye

10 years ago
On Mon, Jul 18, 2016 at 3:41 PM, Niklas Keller <me@kelunik.com> wrote:
> 2016-07-18 9:54 GMT+02:00 Pierre Joye <pierre.php@gmail.com>: >> >> hi, >> >> On Mon, Jul 18, 2016 at 7:12 AM, Davey Shafik <davey@php.net> wrote: >> > The only negative I see for this is that it reinforces PECL as being >> > Siberia. Having said that, it's better than deleting them, and they >> > shouldn't be in core. >> >> I see other, one of them is BC breaks. > > > Moving extensions to PECL is allowed in x.y.z to x.y+1.z: Extensions support > can be ended (moved to pecl) > > See: https://wiki.php.net/rfc/releaseprocess
I wrote it, so yes, I do know that. However allowed does not mean "let do it for any ext at any point release". xmlrpc is still widely used and it does not seem to require a lot of work. It has been stable for a long time and new bugs may be mostly due to 7 migration as we have seen in many other extensions. Cheers,
-- Pierre @pierrejoye | http://www.libgd.org

Stas Malyshev

10 years ago
Hi!
> I wrote it, so yes, I do know that. However allowed does not mean "let > do it for any ext at any point release". xmlrpc is still widely used > and it does not seem to require a lot of work. It has been stable for > a long time and new bugs may be mostly due to 7 migration as we have > seen in many other extensions.
Well, yes and no - see https://bugs.php.net/bug.php?id=72606. Could be argued it's because of 7 migration, but not exactly as the problem existed before, just became easier to trigger (if you want to discuss, let's do it on the bug though :)
-- Stas Malyshev smalyshev@gmail.com

Stas Malyshev

10 years ago
Hi!
> xmlrpc is used quite a lot still (limesurvey f.e. or moodle as this > other reply confirmed), removing without previous warnings or not even > trying to get a maintainer before moving it sounds a bit like a bad > move to me.
Well, we're not destroying the code. Anybody who builds their own can as easily check out PECL repo, and distributions can and do build PECL modules without any problem. The difference is mainly whose responsibility it is. If it's in core, PHP team as a whole bears responsibility on what happens there, and if we don't actually have anybody to maintain it, the claim that we do is a lie, and we're making promises on which we can't deliver. So we should either seek maintainers or admit we don't maintain it. So I don't see it as a BC issue but mainly as an issue of clearly communicating of who is responsible for given extension and what promises we are making. That said, we probably need a bit better procedure on how that process should work, I'll try to write an RFC in my copious free time to set up guidelines and maybe do some re-inventarization of our extensions for 7.1.
-- Stas Malyshev smalyshev@gmail.com

Derick Rethans

10 years ago
On Sun, 17 Jul 2016, Stanislav Malyshev wrote:
> Continuing on this topic, maybe we also should have a review of the > rest of the extensions and check if the ones marked as maintained > still are, and if current maintainers are not active anymore ask for > new ones to be assigned or change their status accordingly?
Don't presume that "no updates" does not mean "not in use", or "not maintained" though. cheers, Derick

Stas Malyshev

10 years ago
Hi!
> Don't presume that "no updates" does not mean "not in use", or "not > maintained" though.
True. I am not concerned about having many updates though but rather having somebody who would make updates if needed. For those two, we officially don't have anybody. I suspect there is a number of extensions which unofficially are in the same positions, due to nobody listed as maintainers, or people listed as maintainers having moved on since and not really interested in being maintainers, or just us having no idea about whether somebody is maintaining or not. We have 20 extensions listed as "Unknown" and among those listed as maintained, also some that nobody officially listed as maintainer has touched the bugs filed for the extension for many years. This is not to imply somebody's fault or make a judgement on the quality of code or importance of the extensions. It is a natural process that maintainers change. But I think we should realistically evaluate what is really maintained and what is not, identify where we have gaps and either solicit help to close these gaps or admit that we don't have the resource to maintain it right now.
-- Stas Malyshev smalyshev@gmail.com