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.

Regards,
Nikita

Hey Nikita,

I'd like to propose using HackerOne instead of bugs.php.net for security
issues: https://www.hackerone.com/company/open-source-community

As both GH and HackerOne user since years now, I can say h1 has actually
a better user experience for security reports than GH issues for bug
reports.

So if we ever move from bugs.php.net to GH I would favour HackerOne for
the security side of things.

Cheers

Matteo Beccati

Development & Consulting - http://www.beccati.com/

Hey Nikita,

I'd like to propose using HackerOne instead of bugs.php.net for security
issues: https://www.hackerone.com/company/open-source-community

Best,
Niklas

Unfortunately I have no familiarity with HackerOne and as such don't know
whether it would work for our purposes. I think an important requirement
for us is that maintainers who are not otherwise involved in security
response can be assigned to (and see) issues.

I'm hazy on the details, but I believe that PHP used to be part of IBB on
HackerOne and was kicked out due to lack of responsiveness (apparently
nobody from the PHP side was actually involved there).

Regards,
Nikita

Hey Derick

Dear Internals,

I think it is a mistake to decide on a whim to move over to GitHub
issues without having evaluated anything else.

GitHub is a proprietary platform, where unlike with the code
repositories, the interactions and issues are not easy to migrate out of
again. It is also now owned by MSFT, and although they are making
friendly noises towards Open Source, I remain largely skeptical (with as
a hint, the stuff they're pulling with AI code completion).

I understand and share that "bugsnet" has many issues, and I don't
necessarily object moving to something else.

However, in the last 25+ years we've always hosted this ourselves, and
this prevented any sort of vendor lock in. I think it is important to
own our own data here, or at least have full access to any interactions.

This jump to GitHub Issues feels rushed, and I worry that we end up
making the wrong decision, especially because from the RFC it seems we
need to build some functionality (tags scheme, for example) on top of
it. And this will need to be maintained separately, and I worry that too
few people are going to be interested in gardening the issues on GH.

I believe we would be much better served having a look what is
available, and see what else is suitable. I'm therefore intending to
vote no on this.

cheers,
Derick

Remember that all information on public repos is also available on
http://www.gharchive.org/
If data retention is the problem, mirroring that could be an effective
solution.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

if hosting it ourself is a priority, i suggest looking into GitLab’s
Community Edition, which is entirely open source,
and the GNOME project moved from Bugzilla to GitLab CE in 2018,
here's how that worked out, 2 years later:
https://about.gitlab.com/blog/2020/09/08/gnome-follow-up/
(and the TL;DR is that it worked out great for the GNOME project)

Dear Internals,

I think it is a mistake to decide on a whim to move over to GitHub
issues without having evaluated anything else.

GitHub is a proprietary platform, where unlike with the code
repositories, the interactions and issues are not easy to migrate out of
again. It is also now owned by MSFT, and although they are making
friendly noises towards Open Source, I remain largely skeptical (with as
a hint, the stuff they're pulling with AI code completion).

I understand and share that "bugsnet" has many issues, and I don't
necessarily object moving to something else.

However, in the last 25+ years we've always hosted this ourselves, and
this prevented any sort of vendor lock in. I think it is important to
own our own data here, or at least have full access to any interactions.

This jump to GitHub Issues feels rushed, and I worry that we end up
making the wrong decision, especially because from the RFC it seems we
need to build some functionality (tags scheme, for example) on top of
it. And this will need to be maintained separately, and I worry that too
few people are going to be interested in gardening the issues on GH.

I believe we would be much better served having a look what is
available, and see what else is suitable. I'm therefore intending to
vote no on this.

cheers,
Derick

Hi internals,

The migration from bugs.php.net to GitHub issues has already been
discussed
in https://externals.io/message/114300 and has already happened for
documentation issues.

I'd like to formally propose to use GitHub for PHP implementation issues
as
well: https://wiki.php.net/rfc/github_issues

Regards,
Nikita

--
PHP 7.4 Release Manager
Host of PHP Internals News: https://phpinternals.news
Like Xdebug? Consider supporting me: https://xdebug.org/support
https://derickrethans.nl | https://xdebug.org | https://dram.io
twitter: @derickr and @xdebug

--

To unsubscribe, visit: https://www.php.net/unsub.php

and I worry that too
few people are going to be interested in gardening the issues on GH.

cheers,
Derick

Hi internals,

The migration from bugs.php.net to GitHub issues has already been
discussed
in https://externals.io/message/114300 and has already happened for
documentation issues.

I'd like to formally propose to use GitHub for PHP implementation issues
as
well: https://wiki.php.net/rfc/github_issues

Regards,
Nikita

--
PHP 7.4 Release Manager
Host of PHP Internals News: https://phpinternals.news
Like Xdebug? Consider supporting me: https://xdebug.org/support
https://derickrethans.nl | https://xdebug.org | https://dram.io
twitter: @derickr and @xdebug

--

To unsubscribe, visit: https://www.php.net/unsub.php

If we do move over to GitHub I know that A LOT of young software engineers
already learn how to use it which reduces the entry barrier. In fact, if
it's possible to help triage bugs without C knowledge, I'm willing to be a
candidate to help out since I know the whole "ticketing system" already, so
it's just a matter of learning about tagging the content. Overall, I think
moving to where developers are is a good decision because it becomes more
accessible for a lot of people that may be willing to help.

Self hosting means that 1) the choice of system will be something that the
pool of people experienced in it will be less than GH Issues 2) someone
will have to maintain the hosting infrastructure for it 3) it will be less
accessible. I'm all for using GH Issues.

--
Marco Aurélio Deleu

GitHub is a proprietary platform, where unlike with the code
repositories, the interactions and issues are not easy to migrate out of
again. It is also now owned by MSFT, and although they are making
friendly noises towards Open Source, I remain largely skeptical (with as
a hint, the stuff they're pulling with AI code completion).

All open-source projects I know and use in relation to PHP development
are on Github (like Composer and Symfony, to just name two big ones),
which in my opinion makes Github an ideal platform for the PHP project
itself, as the barrier of entry is lowered.

This also has the advantage that if Github "becomes evil" (or just gets
worse) for whatever reasons, the PHP project will just be one of many
open-source projects which needs to move to a new place. This gives this
solution a safety in numbers and will probably make it easier to move
rather than harder.

Dear Internals,

I think it is a mistake to decide on a whim to move over to GitHub
issues without having evaluated anything else.

GitHub is a proprietary platform, where unlike with the code
repositories, the interactions and issues are not easy to migrate out of
again. It is also now owned by MSFT, and although they are making
friendly noises towards Open Source, I remain largely skeptical (with as
a hint, the stuff they're pulling with AI code completion).

I understand and share that "bugsnet" has many issues, and I don't
necessarily object moving to something else.

However, in the last 25+ years we've always hosted this ourselves, and
this prevented any sort of vendor lock in. I think it is important to
own our own data here, or at least have full access to any interactions.

This jump to GitHub Issues feels rushed, and I worry that we end up
making the wrong decision, especially because from the RFC it seems we
need to build some functionality (tags scheme, for example) on top of
it. And this will need to be maintained separately, and I worry that too
few people are going to be interested in gardening the issues on GH.

I believe we would be much better served having a look what is
available, and see what else is suitable. I'm therefore intending to
vote no on this.

Hey Derick,

The RFC includes a bit of discussion of alternatives in abstract (
https://wiki.php.net/rfc/github_issues#alternatives) and the key point
(which has also been brought up by other people in the meantime) is that
the choice of GitHub issues is very much not a whim:

For better or worse, GitHub is where nearly all open-source projects are
hosted, which means that pretty much anyone involved in open-source has an
account there and is familiar with the workflows. It is also where PHP
hosts it's repos and where we accept pull requests. An alternative issue
tracker has to compete not just on technical grounds, but also on
integration, familiarity and network-effect. For an open-source project,
these aspects are quite important when it comes to interaction with casual
contributors.

Working at JetBrains, proposing YouTrack instead of GH issues has certainly
crossed my mind -- there is no doubt that at a technical level, it's a much
better bug tracker than GH issues. But that's simply not the right question
to ask. The right question is whether, given our rather simple
requirements, is it sufficiently better to overshadow the other benefits of
GitHub issues for an open-source project? I don't think so. We just need GH
issues to be "good enough" for our purposes, and I think that at this point
it is.

I'll also mention that the discussion about this migration has been going
on for six months, and in that time all I've ever seen are vague mentions
of alternatives, but nobody has provided any in-depth analysis that goes
beyond a simple name drop. I went through the trouble of providing a
detailed evaluation of how the GitHub issues migration will look like,
while the alternatives are still at the state of "Phabricator is a thing"
(ooops, it actually isn't -- it managed to be discontinued while the
discussion was going on!)

Finally, for me an important part of the migration (whether to GH Issues or
something else) is specifically that we don't host it ourselves, because we
have historically always been really bad at that. Of course, letting
someone else host it is incompatible with the desire to fully "own" our
data. I do appreciate the general sentiment here though.

Regards,
Nikita

Derick wrote:

I think it is a mistake to decide on a whim to move over to GitHub
issues without having evaluated anything else.

Maybe avoid being insulting about other people's decision making
process? I'm pretty sure that Nikita doesn't make that many decisions
on a whim, and that he has spent quite a bit of time over the past
couple of weeks/months figuring out how it would work, and getting a
test repo setup with the new issue templates.

And I also believe he has spent signification time evaluating
alternatives, but they all come up across the same problem listed in
the RFC:

"The requirement for an alternative would be that a) it is hosted
(i.e. the PHP project does not need to maintain infrastructure for
it), b) has good GitHub integration and c) is “sufficiently better”
than GitHub issues to make it worth using a separate product."

I don't think the vendor lock-in concern is that great. If Microsoft
actually starts acting evil again, to the extent that we need to stop
using Github for either code or issues, then we would be able to move
again. The lock-in on github doesn't appear to be worse than
bugs.php.net. In fact, it's far more likely that anything we would
move to is going to have an "import from github" button, than anything
having an "import from bugs.php.net" button.

This jump to GitHub Issues feels rushed,

The topic has been discussed for at least 6 months:
https://news-web.php.net/php.internals/114330

That seems like quite a bit of time for people who would prefer to
avoid github to evaluate the alternatives and write out a plan.

cheers
Dan
Ack

On Mon, Nov 15, 2021 at 9:18 PM Björn Larsson bjorn.x.larsson@telia.com
wrote:

Den 2021-11-02 kl. 15:19, skrev Nikita Popov:

Hi internals,

The migration from bugs.php.net to GitHub issues has already been
discussed
in https://externals.io/message/114300 and has already happened for
documentation issues.

I'd like to formally propose to use GitHub for PHP implementation issues
as
well: https://wiki.php.net/rfc/github_issues

Regards,
Nikita

Hi,

The current proposal is to move all new issues from bugs.php.net to
Github except security ones.

I think it's important to think a bit on what that means for reporting
security issues in the future. I mean, if we leave bugs.php.net to rot
in the corner, what are the consequences for reporting security issues?

I think that aspect needs to be a bit further analysed like:

• Will this move have a negative impact on reporting security issues
  on bugs.php.net?

  Both from a technical and people perspective.

• Can one assume that by bugs.php.net having probably even less
  attention, that reporting security issues will work as is?
• Is there an alternative for also handling security issues?

Think it would be good if the RFC could analyse that a little, besides
saying business as usual for security issues.

I don't think there's much more to say than that -- it should indeed be
business as usual. The only complication I see for security issues is that
we will not be able to easily move security issues that turn out to be
non-security bugs over to GitHub. As such, we may have a very low number of
new bugs appearing on bugs.php.net by being reported as security issues
first and being reclassified later. I don't view that as an immediate
problem, because to start with, we'll still be working with recent reports
on bugs.php.net anyway. Longer term, I do hope that GitHub will provide a
way to report issues privately (i.e. as indicated in
https://github.blog/2021-11-12-highlights-github-security-roadmap-universe-2021/),
so that we can consolidate everything in one tracker. But given the lack of
clear roadmap for this, I'm not basing any plans on it yet.

I do think that the handling of security issues is the weakest part of this
move, and probably the only area where choosing a different platform could
have a tangible advantage. However, we receive orders of magnitude less
security issues than other reports, and there is a much smaller number of
people involved in handling them, so I don't think we need to put too
strong a focus on this aspect.

Regards,
Nikita