On Fri, 13 Sept 2024 at 17:18, Gina P. Banyard wrote:
>
> On Wednesday, 11 September 2024 at 16:04, Derick Rethans
> wrote:
> > But XML parsing is such an integral part of PHP, that this absolutely
> > should be in core. For many users, if it's not in core, they can't use
> > it. Or at least tha
On Wednesday, 11 September 2024 at 16:04, Derick Rethans
wrote:
> But XML parsing is such an integral part of PHP, that this absolutely
> should be in core. For many users, if it's not in core, they can't use
> it. Or at least that used to be a big problem.
Is XML parsing such an integral par
On 11.09.2024 at 16:04, Derick Rethans wrote:
> But XML parsing is such an integral part of PHP, that this absolutely
> should be in core. For *many* users, if it's not in core, they can't use
> it. Or at least that used to be a big problem.
We even made ext/json and ext/hash mandatory, so users
On Tue, 10 Sep 2024, Gina P. Banyard wrote:
> On Friday, 30 August 2024 at 20:13, Christoph M. Becker
> wrote:
>
> > Instead I'm saying that we should be careful to unbundle extensions.
> > This should probably seen as a last resort if we absolutely can't
> > maintain the extension any longer
On Sat, 31 Aug 2024, Rob Landers wrote:
> On Fri, Aug 30, 2024, at 20:13, Christoph M. Becker wrote:
> > It's easy to vote "yes, unbundle this extension" if you've never
> > used the extension and are not planning to do so in the future. It
> > may be a death sentence, though.
> >
>
> I went
On Tue, 10 Sept 2024, 22:49 Gina P. Banyard, wrote:
>
> But it is my biggest belief that most extensions would be better outside
> the php-src repo and live in PECL so they could be updated independently
> and not tied to the yearly PHP release schedule.
> The fact that ext/cURL is not allowed to
On Friday, 30 August 2024 at 20:13, Christoph M. Becker
wrote:
> On 30.08.2024 at 19:05, Jim Winstead wrote:
>
> > Perhaps if the effort from the PHP Foundation to build a next-generation
> > PECL bears fruit, an even harder look can be taken at migrating out even
> > more of the extensions s
On Fri, Aug 30, 2024, at 20:13, Christoph M. Becker wrote:
> On 30.08.2024 at 19:05, Jim Winstead wrote:
>
> [snip]
>
> And generally, while there are many well maintained extensions on PECL,
> most (i.e. way more than half of the extension there) are outright
> abandoned, dead or half-dead, a lo
On 30.08.2024 at 19:05, Jim Winstead wrote:
> Perhaps if the effort from the PHP Foundation to build a next-generation PECL
> bears fruit, an even harder look can be taken at migrating out even more of
> the extensions still living in the php-src tree. With some robust CI, care
> could be made
On Fri, Aug 30, 2024, at 9:54 AM, Calvin Buckley wrote:
> On Aug 29, 2024, at 2:49 PM, Christoph M. Becker wrote:
>>
>> Hi all,
>>
>> it seems to me that we're pulling through ext/snmp without having any
>> real expert of the protocol, let alone of the implementation. The
>> extension has no
On Aug 29, 2024, at 2:49 PM, Christoph M. Becker wrote:
>
> Hi all,
>
> it seems to me that we're pulling through ext/snmp without having any
> real expert of the protocol, let alone of the implementation. The
> extension has no code owner, and according to EXTENSIONS, it has no
> primary maint
We have switched to a userland library (https://github.com/FreeDSx/SNMP)
due to crashes when using the internal SNMP extension in ZTS scenarios. It
doesn't really answer your question, but maybe it fits category two, that
usage is not very high or that people chose the pure PHP version.
Michael
A
Hi all,
it seems to me that we're pulling through ext/snmp without having any
real expert of the protocol, let alone of the implementation. The
extension has no code owner, and according to EXTENSIONS, it has no
primary maintainer for more than ten years. Skimming through the commit
log mostly s
13 matches
Mail list logo
