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
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:
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
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
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.
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
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
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.
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
2016-07-18 9:54 GMT+02:00 Pierre Joye pierre.php@gmail.com:
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.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
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
2016-07-18 9:54 GMT+02:00 Pierre Joye pierre.php@gmail.com:
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.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)
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
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
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
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
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