Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116320
MIME-Version: 1.0
References: <CAF+90c90pTtjxuMaQ88h+njhByfbv4qs=xx72CVPSw40tde6Cg@mail.gmail.com>
 <CA+kxMuSmBVqgNdg0n1+aDd9vHC-dpcDK0x8q5Be8U5mVtck9CQ@mail.gmail.com> <CAF+90c_hinbidrXTp7oghqo373VQB9XdeBpp3hF7010_ORH6Zg@mail.gmail.com>
In-Reply-To: <CAF+90c_hinbidrXTp7oghqo373VQB9XdeBpp3hF7010_ORH6Zg@mail.gmail.com>
Date: Thu, 11 Nov 2021 16:03:25 +0100
Message-ID: <CAF+90c9+ZC8aCUO90tjrVpGZ7DTVG-Aqff_J-Ze8dJbizxdU1w@mail.gmail.com>
To: Dan Ackroyd <danack@basereality.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000f5f14c05d084a5f3"
Subject: Re: [PHP-DEV] [RFC] Migrating to GitHub issues
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000f5f14c05d084a5f3
Content-Type: text/plain; charset="UTF-8"

On Wed, Nov 10, 2021 at 5:51 PM Nikita Popov <nikita.ppv@gmail.com> wrote:

> On Thu, Nov 4, 2021 at 5:58 PM Dan Ackroyd <Danack@basereality.com> wrote:
>
>> On Tue, 2 Nov 2021 at 14:19, Nikita Popov <nikita.ppv@gmail.com> wrote:
>> >
>> > I'd like to formally propose to use GitHub for PHP implementation
>> issues as
>> > well: https://wiki.php.net/rfc/github_issues
>>
>> In general, yes please. The only bit I'll chime in on is:
>>
>> > bugs.php.net will remain active for the following purposes:
>> > Reporting of issues against PECL extensions. (We may want to discontinue
>> > this as well. Many actively maintained extensions already use GitHub
>> issues
>> > rather than bugs.php.net.)
>>
>>
>> Providing a bug reporting site was a useful thing to do 23 years ago,
>> as it would have been either expensive or time consuming for each
>> project to set up their own. It doesn't seem as sensible now as:
>>
>> * Having bugs.php.net remain open for some bits of PHP, but not
>> others, would be confusing for users.
>>
>> * Most extensions are hosted on a platform that already provides issue
>> tracking - though it seems quite a few extensions (including Imagick)
>> have not realised that there is a bug tracking setting that can/should
>> be updated on pecl.
>>
>> * There's an ongoing issue of extensions becoming unmaintained over
>> time. If people are opening bugs on the PHP issue tracker, it's
>> natural for them to have an expectation that someone from the PHP
>> project would work on that issue at some point.
>>
>> So unless someone has a strong argument for keeping the bugs.php.net
>> open for PECL extensions, I think it shouldn't be.
>>
>> btw it would probably be useful to dump out a list of where to report
>> bugs for different extensions and put that as a page on bugs.php.net
>> though. If nothing else, Google thinks Imagick is an alias for
>> ImageMagick far too often and sometimes pecl.php.net is unresponsive.
>
>
> Yes, we should definitely migrate PECL extensions away from bugs.php.net
> as well. I didn't cover this in the RFC because it doesn't really relate to
> the setup described there and this part of the migration can happen in
> parallel.
>
> To migrate PECL extensions hosted by the PHP organization away from
> bugs.php.net, we need to:
> 1. Enable GH issues on the repo.
> 2. Disable the package on bugs.php.net.
> 3. Update the bug tracker URL on pecl.php.net.
> 4. (Maybe) manually migrate outstanding open bugs.
>
> For extensions not hosted by the PHP organization we may have to contact
> maintainers to determine which issue tracker to use.
>

As an update here: I've gone through all the PECL packages on bugs.php.net
and found that nearly all of them are either unmaintained or already have a
different bugtracker (almost always GitHub issues). Those packages are now
disabled and cmb has updated the bug tracker URLs on pecl.php.net. Next
step will be to open GH issues for repos that the PHP organization owns,
and then we'll have to see what to do with the handful of remaining
extensions.

I've updated the RFC to say that bugs.php.net to say that it will not
remain open for PECL extensions either.

Regards,
Nikita

--000000000000f5f14c05d084a5f3--