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
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
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
I'd like to formally propose to use GitHub for PHP implementation issues
as
well: https://wiki.php.net/rfc/github_issuesIn 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:
- Enable GH issues on the repo.
- Disable the package on bugs.php.net.
- Update the bug tracker URL on pecl.php.net.
- (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
I'd like to formally propose to use GitHub for PHP implementation
issues as
well: https://wiki.php.net/rfc/github_issuesIn 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:
- Enable GH issues on the repo.
- Disable the package on bugs.php.net.
- Update the bug tracker URL on pecl.php.net.
- (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
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 <nikita.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_issuesRegards,
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-communityBest,
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
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
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_issuesRegards,
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
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
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,
DerickHi 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_issuesRegards,
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 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
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.
and I worry that too
few people are going to be interested in gardening the issues on GH.cheers,
DerickHi 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_issuesRegards,
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
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
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
--
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
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
--
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.
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
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]
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 rowan.collins@gmail.com
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
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
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_issuesRegards,
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
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_issuesRegards,
NikitaHi,
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
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_issuesRegards,
NikitaHi,
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
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
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
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
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
On Thu, Nov 18, 2021 at 2:53 PM Matthew Weier O'Phinney <
mweierophinney@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
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
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
On Fri, Nov 19, 2021 at 9:44 PM Stanislav Malyshev smalyshev@gmail.com
wrote:
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
It looks like GitHub has just added support for private security reports:
https://github.blog/changelog/2022-11-09-privately-report-vulnerabilities-to-repository-maintainers/
I haven't looked into the details, but it probably makes sense to enable
those on php-src and make this our official venue for security bug reports.
This would allow retiring the last remaining use of bugs.php.net (well,
apart from the archive of old issues, which should of course remain).
Regards,
Nikita
It looks like GitHub has just added support for private security reports:
https://github.blog/changelog/2022-11-09-privately-report-vulnerabilities-to-repository-maintainers/I haven't looked into the details, but it probably makes sense to enable
those on php-src and make this our official venue for security bug reports.
This would allow retiring the last remaining use of bugs.php.net (well,
apart from the archive of old issues, which should of course remain).
I agree, but maybe the security team is in favor of sticking with
bugs.php.net.
--
Christoph M. Becker
It looks like GitHub has just added support for private security reports:
https://github.blog/changelog/2022-11-09-privately-report-vulnerabilities-to-repository-maintainers/I haven't looked into the details, but it probably makes sense to enable
those on php-src and make this our official venue for security bug reports.
This would allow retiring the last remaining use of bugs.php.net (well,
apart from the archive of old issues, which should of course remain).I agree, but maybe the security team is in favor of sticking with
bugs.php.net.
I noticed that the php-src repo does enable private vulnerability reports now, and there is one sitting around without response at https://github.com/php/php-src/security/advisories/GHSA-54hq-v5wp-fqgv.
Possibly this was enabled unintentionally / without coordination with the security team? That should probably either be disabled again, or someone needs to keep an eye on it.
Regards,
Nikita
It looks like GitHub has just added support for private security reports:
https://github.blog/changelog/2022-11-09-privately-report-vulnerabilities-to-repository-maintainers/I haven't looked into the details, but it probably makes sense to enable
those on php-src and make this our official venue for security bug reports.
This would allow retiring the last remaining use of bugs.php.net (well,
apart from the archive of old issues, which should of course remain).I agree, but maybe the security team is in favor of sticking with
bugs.php.net.I noticed that the php-src repo does enable private vulnerability reports now, and there is one sitting around without response at https://github.com/php/php-src/security/advisories/GHSA-54hq-v5wp-fqgv.
Possibly this was enabled unintentionally / without coordination with the security team? That should probably either be disabled again, or someone needs to keep an eye on it.
I had enabled that some weeks ago, since there has been a spam attack on
bugsnet, so we could test the new feature. I probably should have
written to list right away, or at least have kept an eye on it, but I've
assumed to be notified about reported issues.
I'll have a closer look at the rather verbose report tomorrow, if nobody
beats me to it.
Generally, I'm in favor of keeping security reports on Github enabled;
we should stop user (not developer) comments on bugsnet as soon as
possible; there is already more spam than useful comments for quite a
while, and I think Github offers better feature to handle that.
Regarding the access rights on security advisories: currently only php
owners[1] may see and collaborate there. To my knowledge, most of those
who are subscribed to the security mailing list are already in that
group, but if need be, others might be added, or maybe it's preferable
to create a new team for this.
Thoughts?
[1] https://github.com/orgs/php/people?query=role%3Aowner
--
Christoph M. Becker
Hi!
I had enabled that some weeks ago, since there has been a spam attack on
bugsnet, so we could test the new feature. I probably should have
written to list right away, or at least have kept an eye on it, but I've
assumed to be notified about reported issues.I'll have a closer look at the rather verbose report tomorrow, if nobody
beats me to it.
I was planning to take a look at it over the weekend, but do not let it
to deter you :)
--
Stas Malyshev
smalyshev@gmail.com
It looks like GitHub has just added support for private security reports:
https://github.blog/changelog/2022-11-09-privately-report-vulnerabilities-to-repository-maintainers/I haven't looked into the details, but it probably makes sense to enable
those on php-src and make this our official venue for security bug reports.
This would allow retiring the last remaining use of bugs.php.net (well,
apart from the archive of old issues, which should of course remain).I agree, but maybe the security team is in favor of sticking with
bugs.php.net.I noticed that the php-src repo does enable private vulnerability reports now, and there is one sitting around without response at https://github.com/php/php-src/security/advisories/GHSA-54hq-v5wp-fqgv.
Possibly this was enabled unintentionally / without coordination with the security team? That should probably either be disabled again, or someone needs to keep an eye on it.
I had enabled that some weeks ago, since there has been a spam attack on
bugsnet, so we could test the new feature. I probably should have
written to list right away, or at least have kept an eye on it, but I've
assumed to be notified about reported issues.I'll have a closer look at the rather verbose report tomorrow, if nobody
beats me to it.Generally, I'm in favor of keeping security reports on Github enabled;
we should stop user (not developer) comments on bugsnet as soon as
possible; there is already more spam than useful comments for quite a
while, and I think Github offers better feature to handle that.Regarding the access rights on security advisories: currently only php
owners[1] may see and collaborate there. To my knowledge, most of those
who are subscribed to the security mailing list are already in that
group, but if need be, others might be added, or maybe it's preferable
to create a new team for this.Thoughts?
Security bug reports on GitHub have been active for a while now, with about 10 reports having been processed.
I wanted to check back whether security folks are happy with the process, and whether it is time to make this the official channel for security reports, which would allow us to disable issue creation on bugs.php.net entirely. (I saw that the reports are 90% spam at this point.)
Regards,
Nikita
It looks like GitHub has just added support for private security reports:
https://github.blog/changelog/2022-11-09-privately-report-vulnerabilities-to-repository-maintainers/I haven't looked into the details, but it probably makes sense to enable
those on php-src and make this our official venue for security bug reports.
This would allow retiring the last remaining use of bugs.php.net (well,
apart from the archive of old issues, which should of course remain).I agree, but maybe the security team is in favor of sticking with
bugs.php.net.I noticed that the php-src repo does enable private vulnerability reports now, and there is one sitting around without response at https://github.com/php/php-src/security/advisories/GHSA-54hq-v5wp-fqgv.
Possibly this was enabled unintentionally / without coordination with the security team? That should probably either be disabled again, or someone needs to keep an eye on it.
I had enabled that some weeks ago, since there has been a spam attack on
bugsnet, so we could test the new feature. I probably should have
written to list right away, or at least have kept an eye on it, but I've
assumed to be notified about reported issues.I'll have a closer look at the rather verbose report tomorrow, if nobody
beats me to it.Generally, I'm in favor of keeping security reports on Github enabled;
we should stop user (not developer) comments on bugsnet as soon as
possible; there is already more spam than useful comments for quite a
while, and I think Github offers better feature to handle that.Regarding the access rights on security advisories: currently only php
owners[1] may see and collaborate there. To my knowledge, most of those
who are subscribed to the security mailing list are already in that
group, but if need be, others might be added, or maybe it's preferable
to create a new team for this.Thoughts?
Security bug reports on GitHub have been active for a while now, with about 10 reports having been processed.
I wanted to check back whether security folks are happy with the process, and whether it is time to make this the official channel for security reports, which would allow us to disable issue creation on bugs.php.net entirely. (I saw that the reports are 90% spam at this point.)
I just realized that our security policy already points at GitHub security advisories rather than bugs.php.net here: https://github.com/php/php-src/security/policy#how-do-i-report-a-security-issue
So I went ahead and submitted a PR to remove support for creation of new bug reports on bugs.php.net: https://github.com/php/web-bugs/pull/115
Regards,
Nikita
It looks like GitHub has just added support for private security reports:
https://github.blog/changelog/2022-11-09-privately-report-vulnerabilities-to-repository-maintainers/I haven't looked into the details, but it probably makes sense to enable
those on php-src and make this our official venue for security bug reports.
This would allow retiring the last remaining use of bugs.php.net (well,
apart from the archive of old issues, which should of course remain).I agree, but maybe the security team is in favor of sticking with
bugs.php.net.I noticed that the php-src repo does enable private vulnerability reports now, and there is one sitting around without response at https://github.com/php/php-src/security/advisories/GHSA-54hq-v5wp-fqgv.
Possibly this was enabled unintentionally / without coordination with the security team? That should probably either be disabled again, or someone needs to keep an eye on it.
I had enabled that some weeks ago, since there has been a spam attack on
bugsnet, so we could test the new feature. I probably should have
written to list right away, or at least have kept an eye on it, but I've
assumed to be notified about reported issues.I'll have a closer look at the rather verbose report tomorrow, if nobody
beats me to it.Generally, I'm in favor of keeping security reports on Github enabled;
we should stop user (not developer) comments on bugsnet as soon as
possible; there is already more spam than useful comments for quite a
while, and I think Github offers better feature to handle that.Regarding the access rights on security advisories: currently only php
owners[1] may see and collaborate there. To my knowledge, most of those
who are subscribed to the security mailing list are already in that
group, but if need be, others might be added, or maybe it's preferable
to create a new team for this.Thoughts?
Security bug reports on GitHub have been active for a while now, with about 10 reports having been processed.
I wanted to check back whether security folks are happy with the process, and whether it is time to make this the official channel for security reports, which would allow us to disable issue creation on bugs.php.net entirely. (I saw that the reports are 90% spam at this point.)
Regards,
Nikita
FWIW, if you press the "new issue" button on GitHub you get to this page: https://github.com/php/php-src/issues/new/choose
If you choose the last option "Security Issue" you still get redirected to the bugs.php.net bugtracker.
Interestingly, there's also a "Report a security vulnerability" option in the middle which brings you to the private report page on GitHub.
I guess this should be updated too.
Kind regards
Niels