[RFC] Migrating to GitHub issues

  116302
November 2, 2021 14:19 nikita.ppv@gmail.com (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
  116303
November 3, 2021 15:28 pollita@php.net (Sara Golemon)
On Tue, Nov 2, 2021 at 9:19 AM Nikita Popov ppv@gmail.com> wrote:

> 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 > > IMO the more custom infra we get rid of the better. I'll volunteer to
update the news2html script we use for creating Changelog files. -Sara
  116305
November 4, 2021 16:58 Danack@basereality.com (Dan Ackroyd)
On Tue, 2 Nov 2021 at 14:19, Nikita Popov 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. cheers Dan Ack
  116315
November 10, 2021 16:51 nikita.ppv@gmail.com (Nikita Popov)
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 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. Regards, Nikita
  116320
November 11, 2021 15:03 nikita.ppv@gmail.com (Nikita Popov)
On Wed, Nov 10, 2021 at 5:51 PM Nikita Popov 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 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
  116316
November 10, 2021 18:23 me@kelunik.com (Niklas Keller)
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

Am Di., 2. Nov. 2021 um 15:19 Uhr schrieb Nikita Popov ppv@gmail.com
>:
> 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 >
  116317
November 10, 2021 20:17 php@beccati.com (Matteo Beccati)
On 10/11/2021 19:23, Niklas Keller wrote:
> 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/
  116321
November 11, 2021 15:13 nikita.ppv@gmail.com (Nikita Popov)
On Wed, Nov 10, 2021 at 7:23 PM Niklas Keller <me@kelunik.com> wrote:

> 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
  116348
November 14, 2021 17:14 nikita.ppv@gmail.com (Nikita Popov)
On Tue, Nov 2, 2021 at 3:19 PM Nikita Popov ppv@gmail.com> wrote:

> 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 >
As a heads up, voting on this RFC starts in two days. Regards, Nikita
  116354
November 15, 2021 09:47 derick@php.net (Derick Rethans)
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


On Tue, 2 Nov 2021, Nikita Popov wrote:

> 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
  116356
November 15, 2021 09:55 ocramius@gmail.com (Marco Pivetta)
Hey Derick

On Mon, Nov 15, 2021 at 10:47 AM Derick Rethans <derick@php.net> wrote:

> 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/
  116357
November 15, 2021 09:55 divinity76@gmail.com (Hans Henrik Bergan)
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)


On Mon, 15 Nov 2021 at 10:47, Derick Rethans <derick@php.net> wrote:

> 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 > > > On Tue, 2 Nov 2021, Nikita Popov wrote: > > > 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 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > >
  116384
November 15, 2021 17:37 Danack@basereality.com (Dan Ackroyd)
On Mon, 15 Nov 2021 at 09:56, Hans Henrik Bergan <divinity76@gmail.com> wrote:
> > if hosting it ourself is a priority,
No, quite the opposite. The PHP project is pretty terrible at running infrastructure, as infrastructure needs to have people available to work on it immediately when there are issues, which is not a good match a volunteer project. There is also the problem that a lot of maintenance needed for sites (or things like PEAR/PECL) are very boring, and so they are allowed to rot for years. Even if we had the resources to host something ourselves, doing so would come at an opportunity cost of not doing something that provides better value for the time. cheers Dan Ack
  116401
November 16, 2021 04:32 internals@lists.php.net ("Levi Morrison via internals")
> 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)
In my opinion, _not hosting it ourselves_ is a priority. Part of what bugs.php.net has shown is there is a lack of people who want and are willing to do the systems and maintenance tasks to run our own infrastructure. In this sense, I quite like GitHub, as it is one less thing that we have to maintain. Sure, we will have some custom tags, but this is quite minor compared to maintaining a system.
  116358
November 15, 2021 10:05 deleugyn@gmail.com (Deleu)
On Mon, Nov 15, 2021 at 10:47 AM Derick Rethans <derick@php.net> wrote:

> > and I worry that too > few people are going to be interested in gardening the issues on GH. > > cheers, > Derick > > > On Tue, 2 Nov 2021, Nikita Popov wrote: > > > 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 > > -- > PHP Internals - PHP Runtime Development Mailing List > 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
  116359
November 15, 2021 10:23 a.leathley@gmx.net (Andreas Leathley)
On 15.11.21 10:47, Derick Rethans wrote:
> 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.
  116361
November 15, 2021 11:06 nikita.ppv@gmail.com (Nikita Popov)
On Mon, Nov 15, 2021 at 10:47 AM Derick Rethans <derick@php.net> wrote:

> 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
  116374
November 15, 2021 14:07 come@chilliet.eu (=?ISO-8859-1?Q?C=F4me?= Chilliet)
I strongly agree with Derick on this matter.

Le lundi 15 novembre 2021, 12:06:54 CET Nikita Popov a écrit :
> 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.
I do think that this is for worse, and that this situation exists because of decision like the one PHP is about to make. Saying we should use github because other projects use it is part of the problem. If PHP makes the switch we are encouraging other projects to do the same as well. We would be actively participating in this centralisation.
> It is also where PHP > hosts it's repos and where we accept pull requests.
Which I also think is a problem. A smaller one because of how git is distributed, but still annoying. The decision to move to github for the repositories was done in a hurry because of a security issue. It was the right decision to answer to the urgency of the situation back then I think, but it should not be used as a reason to go deeper down the rabbit hole.
> 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!)
I would like to suggest gitlab.com, which does provide hosting for free for opensource projects: https://about.gitlab.com/solutions/open-source/ Anyone with a github account can use it to log in. It should be easy to migrate to any other gitlab instance if needed. There are even plans to one day have federation over gitlab instances. Not anytime soon, but likely sooner than github which is only hosted by Microsoft. Côme
  116375
November 15, 2021 14:49 deleugyn@gmail.com (Deleu)
> > > I would like to suggest gitlab.com, which does provide hosting for free > for opensource projects: https://about.gitlab.com/solutions/open-source/ > Anyone with a github account can use it to log in. > It should be easy to migrate to any other gitlab instance if needed. There > are even plans to one day have federation over gitlab instances. Not > anytime soon, but likely sooner than github which is only hosted by > Microsoft. > > Côme > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > > Gitlab is not where the wide PHP Community is located. Composer,
widely-used and adopted packages, frameworks, PSRs, PHP itself and PHP Docs are all hosted on GitHub. Choosing something else increases the barrier for newcomers to become contributors. I speak from experience that when I tried to contribute to Alpine Linux, one of the major turn off was GitLab hosting. I had already decided to spend time and effort learning about the project and then having to learn about their ticketing system and git repository is just unnecessary extra work. PHP should not distance itself from its user base. -- Marco Aurélio Deleu
  116378
November 15, 2021 16:55 neclimdul@gmail.com (James Gilliland)
On Mon, Nov 15, 2021 at 8:49 AM Deleu <deleugyn@gmail.com> wrote:

> > > > > > I would like to suggest gitlab.com, which does provide hosting for free > > for opensource projects: https://about.gitlab.com/solutions/open-source/ > > Anyone with a github account can use it to log in. > > It should be easy to migrate to any other gitlab instance if needed. > There > > are even plans to one day have federation over gitlab instances. Not > > anytime soon, but likely sooner than github which is only hosted by > > Microsoft. > > > > Côme > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: https://www.php.net/unsub.php > > > > > Gitlab is not where the wide PHP Community is located. Composer, > widely-used and adopted packages, frameworks, PSRs, PHP itself and PHP Docs > are all hosted on GitHub. Choosing something else increases the barrier for > newcomers to become contributors. I speak from experience that when I tried > to contribute to Alpine Linux, one of the major turn off was GitLab > hosting. I had already decided to spend time and effort learning about the > project and then having to learn about their ticketing system and git > repository is just unnecessary extra work. > > PHP should not distance itself from its user base. > > Drupal Is currently in the process of migrating to a self hosted Gitlab
instance. For some of the reasons highlighted by Derick but also because Github's issues and collaboration can be pretty terrible. There's hints of issue improvements on the horizon but we'll see. Gitlab however has been great in collaborating with us in addressing issues and collaborating on supporting our credit system. My impression is that Gnome switched because of the level of support and interest in Open Source communities so I wouldn't write them off without taking a look.
  116379
November 15, 2021 17:01 come@chilliet.eu (=?ISO-8859-1?Q?C=F4me?= Chilliet)
Le lundi 15 novembre 2021, 15:49:04 CET Deleu a écrit :
> Gitlab is not where the wide PHP Community is located. Composer, > widely-used and adopted packages, frameworks, PSRs, PHP itself and PHP Docs > are all hosted on GitHub. Choosing something else increases the barrier for > newcomers to become contributors. I speak from experience that when I tried > to contribute to Alpine Linux, one of the major turn off was GitLab > hosting. I had already decided to spend time and effort learning about the > project and then having to learn about their ticketing system and git > repository is just unnecessary extra work.
This is exactly the problem with moving to Github, we are forcing everyone to come with us, as others are inciting us to go there by being there (composer, …). Then people only know how to use Github and we are stuck there forever. If we survived all these years with bugs.php.net, we should be alright with gitlab for sure. I think the PHP project could lead the way out of github instead of following the others in. Côme
  116380
November 15, 2021 17:06 rowan.collins@gmail.com (Rowan Tommins)
On 15/11/2021 14:49, Deleu wrote:
> I had already decided to spend time and effort learning about the > project and then having to learn about their ticketing system and git > repository is just unnecessary extra work.
In any project above a handful of developers, learning the conventions and expectations of the community is always going to be far more complicated than learning how to use the actual tools in question. We should definitely choose a tool that is *easy to use*, and easy to authenticate on (but not so easy it fills up with spam, like the current one), but saying that developers will struggle to use anything other than the One True Website is frankly insulting to the intelligence of the average developer. Regards, -- Rowan Tommins [IMSoP]
  116383
November 15, 2021 17:27 ocramius@gmail.com (Marco Pivetta)
Chiming in, since it seems like people are suggesting Gitlab and further
"exotic" tools.

On Mon, Nov 15, 2021 at 6:06 PM Rowan Tommins collins@gmail.com>
wrote:

> On 15/11/2021 14:49, Deleu wrote: > > I had already decided to spend time and effort learning about the > > project and then having to learn about their ticketing system and git > > repository is just unnecessary extra work. > > > In any project above a handful of developers, learning the conventions > and expectations of the community is always going to be far more > complicated than learning how to use the actual tools in question. We > should definitely choose a tool that is *easy to use*, and easy to > authenticate on (but not so easy it fills up with spam, like the current > one), but saying that developers will struggle to use anything other > than the One True Website is frankly insulting to the intelligence of > the average developer. > > The point of using Github (over other tools) is:
* the community is already there * the repository is already frikken there * it's about pumping stuff into the issue tracker, nothing new is added * integrated CVE reports that already fit within the ecosystem * 2fa auth requirement for organization members (gitlab has this too, AFAIK, but it's a checkbox to add somewhere) * including pre-existing users in discussions (yes, leading to pings), even those that didn't declare a public mail - no registration and no GDPR to manage on PHP-SRC's end * rich editing of issues, with code fragments from the repo, rather than copy-pasta'd stuff all over the place * cross-linking of PHP sources with other project sources, including backlink references that make bugs and workarounds easier to follow by community members This stuff is not to be under-estimated: going self-hosted means having yet another insular environment, where the PHP-SRC folks are trapped in a bit of a void, and the actual discussions will keep happening on PHP-SRC diffs anyway. Instead of fearing the "One True Website", adopt and plan for disaster, should it become an Evil Corp seeding ground: what is there to be lost, and how hard would it be to recover? Greets, Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/
  116385
November 15, 2021 17:59 Danack@basereality.com (Dan Ackroyd)
On Mon, 15 Nov 2021 at 09:47, Derick Rethans <derick@php.net> wrote:

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
  116390
November 15, 2021 20:18 internals@lists.php.net ("Björn Larsson via internals")
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. Regards //Björn L
  116437
November 17, 2021 12:01 nikita.ppv@gmail.com (Nikita Popov)
On Mon, Nov 15, 2021 at 9:18 PM Björn Larsson 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
  116438
November 17, 2021 12:29 cmbecker69@gmx.de ("Christoph M. Becker")
On 17.11.2021 at 13:01, Nikita Popov wrote:

> On Mon, Nov 15, 2021 at 9:18 PM Björn Larsson 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.
Right. An alternative might be to let users report security issues to the security mailing list, where, if the issue turns out not to be a security issue, the reporter could still be asked to submit a GH issue about the bug. In that case it might be useful to add more devs to the security mailing list. Christoph
  116446
November 18, 2021 13:07 patrickallaert@php.net (Patrick ALLAERT)
Le mer. 17 nov. 2021 à 13:30, Christoph M. Becker <cmbecker69@gmx.de> a écrit :
> Right. An alternative might be to let users report security issues to > the security mailing list, where, if the issue turns out not to be a > security issue, the reporter could still be asked to submit a GH issue > about the bug. In that case it might be useful to add more devs to the > security mailing list.
I was thinking about the same. Can't we work with security issues with mailing list *only*? It doesn't feel optimal to keep bugs.php.net active for just security ones. I miss seeing the motivation for it. Patrick
  116447
November 18, 2021 13:32 nikita.ppv@gmail.com (Nikita Popov)
On Thu, Nov 18, 2021 at 2:07 PM Patrick ALLAERT <patrickallaert@php.net>
wrote:

> Le mer. 17 nov. 2021 à 13:30, Christoph M. Becker <cmbecker69@gmx.de> a > écrit : > > Right. An alternative might be to let users report security issues to > > the security mailing list, where, if the issue turns out not to be a > > security issue, the reporter could still be asked to submit a GH issue > > about the bug. In that case it might be useful to add more devs to the > > security mailing list. > > I was thinking about the same. Can't we work with security issues with > mailing list *only*? > It doesn't feel optimal to keep bugs.php.net active for just security > ones. > I miss seeing the motivation for it. >
The problem with the security mailing list is that it's ephemeral -- someone new can't look at past discussions before they were subscribed. Additionally, it's not possible to make the issue and the whole conversation around it public after the issue has been fixed. Regards, Nikita
  116448
November 18, 2021 13:53 mweierophinney@gmail.com ("Matthew Weier O'Phinney")
On Thu, Nov 18, 2021, 7:32 AM Nikita Popov ppv@gmail.com> wrote:

> On Thu, Nov 18, 2021 at 2:07 PM Patrick ALLAERT <patrickallaert@php.net> > wrote: > > > Le mer. 17 nov. 2021 à 13:30, Christoph M. Becker <cmbecker69@gmx.de> a > > écrit : > > > Right. An alternative might be to let users report security issues to > > > the security mailing list, where, if the issue turns out not to be a > > > security issue, the reporter could still be asked to submit a GH issue > > > about the bug. In that case it might be useful to add more devs to the > > > security mailing list. > > > > I was thinking about the same. Can't we work with security issues with > > mailing list *only*? > > It doesn't feel optimal to keep bugs.php.net active for just security > > ones. > > I miss seeing the motivation for it. > > > > The problem with the security mailing list is that it's ephemeral -- > someone new can't look at past discussions before they were subscribed. > Additionally, it's not possible to make the issue and the whole > conversation around it public after the issue has been fixed. >
With Laminas, we use an email alias to allow researchers to report to us. We then post the full report as a security issue on GitHub - it's a feature they rolled out late 2019/early 2020 that restricts visibility to maintainers initially, but allows inviting others to collaborate (we invite the reporter immediately, for instance). It also creates a private branch for collaboration. When the patch has been merged, you can mark the issue public. If the plan is to move to GH anyways, this could solve security reporting.
> Regards, > Nikita >
  116449
November 18, 2021 14:11 cmbecker69@gmx.de ("Christoph M. Becker")
On 18.11.2021 at 14:53, Matthew Weier O'Phinney wrote:

> With Laminas, we use an email alias to allow researchers to report to us.. > We then post the full report as a security issue on GitHub - it's a feature > they rolled out late 2019/early 2020 that restricts visibility to > maintainers initially, but allows inviting others to collaborate (we invite > the reporter immediately, for instance). It also creates a private branch > for collaboration. When the patch has been merged, you can mark the issue > public. > > If the plan is to move to GH anyways, this could solve security reporting.
Thanks! I wasn't aware of that feature. More info at <https://docs.github.com/en/code-security/security-advisories/creating-a-security-advisory>. -- Christoph M. Becker
  116450
November 18, 2021 14:19 nikita.ppv@gmail.com (Nikita Popov)
On Thu, Nov 18, 2021 at 2:53 PM Matthew Weier O'Phinney <
mweierophinney@gmail.com> wrote:

> > > On Thu, Nov 18, 2021, 7:32 AM Nikita Popov ppv@gmail.com> wrote: > >> On Thu, Nov 18, 2021 at 2:07 PM Patrick ALLAERT <patrickallaert@php.net> >> wrote: >> >> > Le mer. 17 nov. 2021 à 13:30, Christoph M. Becker <cmbecker69@gmx..de> a >> > écrit : >> > > Right. An alternative might be to let users report security issues to >> > > the security mailing list, where, if the issue turns out not to be a >> > > security issue, the reporter could still be asked to submit a GH issue >> > > about the bug. In that case it might be useful to add more devs to >> the >> > > security mailing list. >> > >> > I was thinking about the same. Can't we work with security issues with >> > mailing list *only*? >> > It doesn't feel optimal to keep bugs.php.net active for just security >> > ones. >> > I miss seeing the motivation for it. >> > >> >> The problem with the security mailing list is that it's ephemeral -- >> someone new can't look at past discussions before they were subscribed. >> Additionally, it's not possible to make the issue and the whole >> conversation around it public after the issue has been fixed. >> > > With Laminas, we use an email alias to allow researchers to report to us. > We then post the full report as a security issue on GitHub - it's a feature > they rolled out late 2019/early 2020 that restricts visibility to > maintainers initially, but allows inviting others to collaborate (we invite > the reporter immediately, for instance). It also creates a private branch > for collaboration. When the patch has been merged, you can mark the issue > public. >
Thanks for the suggestion! That does sound generally viable to me. Just to clarify, this is not making use of issues, but rather of "advisories", which GH implements as an independent feature. I'm not involved in security response, so I can't say whether the security group would want to adopt such a process. This is probably something that should be decided among the people who handle security issues, rather than here. Regards, Nikita
  116451
November 18, 2021 14:36 cmbecker69@gmx.de ("Christoph M. Becker")
On 18.11.2021 at 15:19, Nikita Popov wrote:

> On Thu, Nov 18, 2021 at 2:53 PM Matthew Weier O'Phinney < > mweierophinney@gmail.com> wrote: > >> With Laminas, we use an email alias to allow researchers to report to us. >> We then post the full report as a security issue on GitHub - it's a feature >> they rolled out late 2019/early 2020 that restricts visibility to >> maintainers initially, but allows inviting others to collaborate (we invite >> the reporter immediately, for instance). It also creates a private branch >> for collaboration. When the patch has been merged, you can mark the issue >> public. > > Thanks for the suggestion! That does sound generally viable to me. Just to > clarify, this is not making use of issues, but rather of "advisories", > which GH implements as an independent feature. > > I'm not involved in security response, so I can't say whether the security > group would want to adopt such a process. This is probably something that > should be decided among the people who handle security issues, rather than > here.
Yeah, I suggest to decouple the security reporting issue from this RFC. That can and should be decided by other people, and wouldn't need an RFC, in my opinion. Just a quick note here, that the handling of security reports is rather suboptimal on bugsnet. Patches need to be shared via secrets Gists (or similar) since even the reporter can't access attached patches. -- Christoph M. Becker
  116466
November 19, 2021 20:43 smalyshev@gmail.com (Stanislav Malyshev)
Hi!

 > With Laminas, we use an email alias to allow researchers to report to us.
 > We then post the full report as a security issue on GitHub - it's a 
feature
 > they rolled out late 2019/early 2020 that restricts visibility to
 > maintainers initially, but allows inviting others to collaborate (we 
invite
 > the reporter immediately, for instance). It also creates a private branch
 > for collaboration. When the patch has been merged, you can mark the issue
 > public.
 >
 > If the plan is to move to GH anyways, this could solve security 
reporting.

Not familiar with it, but on the initial look it seems it could work, 
with one caveat. We have a ton of reports which aren't security issues 
and some which need to be discussed before we are sure which one is that.

We could do it on the list, of course, but that creates the same dangers 
as mentioned before - too easy to lose info in an un-archived ML.
-- 
Stas Malyshev
smalyshev@gmail.com