Everything

php

Home » Project » Newsgroups » php.internals » Bugsnet »

Bugsnet

php.internals

Joe Watkins

5 years ago

Morning internals,

We have a spam problem on bugsnet, it's not a new problem. Nikita had to
waste time deleting 20 odd messages from bugsnet yesterday and this is a
common, daily occurrence. We clearly don't have time for this.

Quite aside from spam problems, bugsnet is hidden away in a dark corner of
the internet that requires a special login, doesn't integrate with source
code or our current workflow (very nicely), and doesn't get updated or
developed.

Having moved our workflow to github, now seems to be the time to seriously
consider retiring bugsnet for general use, and using the tools that are
waiting for us - Github Issues.

I'm aware that bugsnet serves as the disclosure method for security bugs
and github doesn't have a solution to that. Leaving that to one side for
now ...

I'm also aware that bugsnet carries with it 20 years worth of crusty old
feature requests and bugs, that are never realistically going to be dealt
with. In the past I've spent time trying to close very old bugs that no
longer seem relevant, the fact is that there are so many of these that I
don't think I made a dent.

It seems obvious that we don't want to migrate all of the data on bugsnet,
but nor do we want to loose the most recent and relevant reports.

I propose that we disable bugsnet for all but security issues leaving
responsible disclosure method to be handled in some other way at a later
date. Leaving bugsnet in a (mostly) readonly mode.

We then send a notification to all bugs that were opened against a specific
and supported version of PHP, notifying the opener of the change and
requesting that they take a couple of minutes to open their issue on github.

I think we might get quite a good response here - anyone suffering the
worst consequences of bugs - production servers can't be upgraded and so on
- are already waiting for a notification from bugsnet, I'm sure the
majority of them will do as we ask.

In some set number of weeks (to be decided), and depending on the response
to our switching over to github, we can try to determine at that time if
it's worth trying to import any data from bugsnet. We can also consider at
this time when it might be appropriate to retire bugsnet entirely.

We will not be free of spam simply by moving, but github has the tools we
need to moderate the content properly - you can block people. In addition,
I feel people are less likely to misbehave if they think their co-workers
or employers might be able to see what they are doing, which may have an
effect also.

It may be over optimistic, but we might get better engagement with bugs on
github than anywhere else also - Github is where people are tending to do
their business today.

Github is maintained, hosted, developed, and free, and while it isn't the
perfect tool for the job, nothing else is either. We could spend time
(which we don't have) developing bugsnet, or installing some other solution
in a dark corner of the internet, and solve no problems at all, and be
burdened with the ongoing maintenance of that solution.

The people who have to spend the most time on this are release managers,
and so while I'm talking to everyone, it is release managers opinions that
I'm most interested in, they are the people who will be and have been most
effected by the shortcomings in bugsnet, whose opinions are most relevant
in this space.

I don't think a vote is appropriate, this decision should be made by the
people whose "jobs" are directly effected - with input from the community,
of course. Not least of all, it will take a month to close a vote, by which
time we will have wasted another (working) day or more of Nikitas time.
Having said all that, I am looking for a consensus before we take any
action. My arm can be twisted, but this is my current position and I think
it's a reasonable one.

On the issue of responsible disclosure ... we can treat this separately,
with the recent change in the workflow, this process is in need of review
anyway. How that is handled should be decided by the people who have a hand
in that process, and so it seems prudent to leave it aside for now.

Cheers
Joe

Sebastian Bergmann

5 years ago

Am 09.05.2021 um 08:48 schrieb Joe Watkins:

> Having moved our workflow to github, now seems to be the time to seriously
> consider retiring bugsnet for general use, and using the tools that are
> waiting for us - Github Issues.

Yes, please. Thank you for proposing this!

> I propose that we disable bugsnet for all but security issues leaving
> responsible disclosure method to be handled in some other way at a later
> date. Leaving bugsnet in a (mostly) readonly mode.
>
> We then send a notification to all bugs that were opened against a specific
> and supported version of PHP, notifying the opener of the change and
> requesting that they take a couple of minutes to open their issue on github.

Sounds reasonable to me.

Kalle Sommer Nielsen

5 years ago

Den søn. 9. maj 2021 kl. 09.49 skrev Joe Watkins <krakjoe@php.net>:

>
> Morning internals,
>
> We have a spam problem on bugsnet, it's not a new problem. Nikita had to
> waste time deleting 20 odd messages from bugsnet yesterday and this is a
> common, daily occurrence. We clearly don't have time for this.

Big +1 from my side. Much like Joe, I have tried a couple of times
over the years to keep the old bugsnet up to date, but it is simply
not possible to do in its current state -- for example, there is still
open feature requests from 2001 there. One can also open that it can
keep other spammers and abusers away from the platform such as the
ever so recurring abuse of Reindl Harald.

I only think the transition period will be difficult, but it should
iron itself out after a year or so (hopefully) and I assume that by
then, we could perhaps have a better medium or idea of how to deal
with security bugs based on the tools available to us after some time
of using Github on a project of the scale of PHP.

I also fully agree that it is not something we should vote on, it is
one of those things that those who actively work on PHP should decide
(to semi quote Rasmus) -- Let's make it happen.

--
regards,

Kalle Sommer Nielsen
kalle@php.net

Stas Malyshev

5 years ago

Hi!

> Quite aside from spam problems, bugsnet is hidden away in a dark corner
> of the internet that requires a special login, doesn't integrate with
> source code or our current workflow (very nicely), and doesn't get
> updated or developed.
>
> Having moved our workflow to github, now seems to be the time to
> seriously consider retiring bugsnet for general use, and using the tools
> that are waiting for us - Github Issues.

I know my opinion here probably doesn't carry a lot of weight since I am
not the one maintaining bugs day to day (and probably don't have much
time to allocate to it) but that's what I've got.

It is not good that our infrastructure is "hidden away in a dark
corner", and it is true that bugs needs some TLC for a while. But Github
Issues frankly sucks big time as a bug management system. It's hard to
fault them as it's not their core business - but while it may be
adequate for a small project, I don't see how Github system could be
manageable with any serious volume. Let me list all it is lacking that
we have right now, with current old and dusty bugs:

1. Bug reporting template
2. Pre-filter on reported bugs
3. Advanced search
4. Custom fields like PHP version or CVE ID
5. Private bugs that are accessible only to members of security team
6. Custom statuses (I guess can be worked around with labels, but would
require a lot of work to make it convenient to use, default screen would
be pretty much unusable due to clutter, as it only understands closed/open)
7. Ability for anybody to submit a bug without opening github account
(yes, I know it also produces the spam problem) and assigning bugs to
people that don't have github account (we still can accept patches from
those, can't we?).
8. Statistics

> It may be over optimistic, but we might get better engagement with bugs
> on github than anywhere else also - Github is where people are tending
> to do their business today.

I think it's way to generic statement. Some people choose github for
doing some stuff would be more accurate. I don't think I can remember
from the top of my head any major project that uses Github as their main
bug tracker. Maybe they exist, but I certainly can't recall any.

> Github is maintained, hosted, developed, and free, and while it isn't
> the perfect tool for the job, nothing else is either. We could spend
> time (which we don't have) developing bugsnet, or installing some other
> solution in a dark corner of the internet, and solve no problems at all,
> and be burdened with the ongoing maintenance of that solution.

Why we must install it in a dark corner? Maybe we should ask for some
help from people who are willing to contribute before we decide to scrap
the whole thing.

Besides that, I am not sure I am feeling that comfortable with moving
100% of the infrastructure of the PHP project to a platform wholly owned
by Microsoft, and that's where things seem to be heading. I know
Microsoft is almost not evil now, and it has no problem with PHP
whatsoever, but things change, and who knows what would happen in
another 5-10 years. I am not sure hard-binding the whole project to a
single platform owned by a single company is that great. Due to the
distributed nature of Git, the repository hosting is very low risk - it
could be easily moved anywhere. But having the rest of the
infrastructure in a single point of failure does not feel great. Once we
move in there, it would be very hard to move out.

Maybe it's just my paranoia speaking, but I think this is also something
we should be considering.

--
Stas Malyshev
smalyshev@gmail.com

Sebastian Bergmann

5 years ago

Am 09.05.2021 um 09:33 schrieb Stanislav Malyshev:

> 1. Bug reporting template

GitHub Issues has support for reporting templates.

For instance, clicking "New issue" on
https://github.com/symfony/symfony/issues will lead to you
https://github.com/symfony/symfony/issues/new/choose. This is an overview
of the reporting templates supported by the Symfony project.

These templates are managed in version control:
https://github.com/symfony/symfony/tree/5.x/.github/ISSUE_TEMPLATE

The feature is documented here:
https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/configuring-issue-templates-for-your-repository

Joe Watkins

5 years ago

Hi Stas,

I did mention that we're leaving aside the sec issue for now.

>  Let me list all it is lacking that

we have right now, with current old and dusty bugs:

1)
https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/configuring-issue-templates-for-your-repository
2) Not sure what this means ?
3) The interface sucks a little, but the options are mostly supported:
https://docs.github.com/en/github/searching-for-information-on-github/searching-issues-and-pull-requests
4 & 6) Tags seem to be the solution here
7) What appears a disadvantage to you appears to be an advantage to me.

> I am not sure I am feeling that comfortable with moving

100% of the infrastructure of the PHP project to a platform wholly owned
by Microsoft,

Sorry, but this sounds like paranoia that I'm not willing to engage.

> who knows what would happen in another 5-10 years

It's true, things change, let's deal with the problems we actually have,
instead of ones we imagine might happen.

> I am not sure hard-binding the whole project to a single platform owned

by a single company is that great.

At one time, all of the infrastructure being under our control, which you
think is ideal, actually meant that the infrastructure for one of the most
important pieces of tech on the web was
surviving on handouts, with not enough resources to maintain or develop the
software we, and so everybody else, was relying on.

We are suffering the direct consequences of these decisions today.

If at some time in the future, github becomes a less than suitable
environment for us, we can just move, no problem. There's no sense in which
we are locked into anything.

> Maybe it's just my paranoia speaking

It seems like we agree :D

We need to make things better, and I'm not saying that github is perfect or
I have all the answers, but feel strongly that we'll be better served by
moving right now.

Thanks for input Stas ...

Cheers
Joe


On Sun, 9 May 2021 at 09:33, Stanislav Malyshev <smalyshev@gmail.com> wrote:

Stas Malyshev

5 years ago

Hi!

> If at some time in the future, github becomes a less than suitable
> environment for us, we can just move, no problem. There's no sense in
> which we are locked into anything.

I don't see how we could "just move" if all our bug handling would be
wired into Github. I can easily see how we could move a repo to any
provider that supports git - git is a generic platform, Github is just a
frontend. But there's no alternative frontend for Github Issues that we
could just copy the data into - you move, you lose your existing system.
There are probably import tools on some platforms, but the processes,
assignments, etc. - all will have to be re-developed, even if we could
re-use the raw data.

--
Stas Malyshev
smalyshev@gmail.com

Mark Randall

5 years ago

On 09/05/2021 09:05, Stanislav Malyshev wrote:

> I don't see how we could "just move" if all our bug handling would be
> wired into Github. I can easily see how we could move a repo to any
> provider that supports git - git is a generic platform, Github is just a
> frontend. But there's no alternative frontend for Github Issues that we
> could just copy the data into - you move, you lose your existing system.
> There are probably import tools on some platforms, but the processes,
> assignments, etc. - all will have to be re-developed, even if we could
> re-use the raw data.

If Github does something so outrageous that a move is required, it is
unlikely to just be PHP that is affected.

Such an eventuality would be all but certain to result in a huge
cross-community effort to develop automated migration tools.

Tools such as github already have integrations that allow migrating
Github data into their own formats.

I personally am not at all worried about having bugs on github.

Pierre Joye

5 years ago

Hi Stas,

On Sun, May 9, 2021, 3:06 PM Stanislav Malyshev <smalyshev@gmail.com> wrote:

> Hi!
>
> > If at some time in the future, github becomes a less than suitable
> > environment for us, we can just move, no problem. There's no sense in
> > which we are locked into anything.
>
> I don't see how we could "just move" if all our bug handling would be
> wired into Github. I can easily see how we could move a repo to any
> provider that supports git - git is a generic platform, Github is just a
> frontend. But there's no alternative frontend for Github Issues that we
> could just copy the data into - you move, you lose your existing system.
>   There are probably import tools on some platforms, but the processes,
> assignments, etc. - all will have to be re-developed, even if we could
> re-use the raw data.
>

You and Joe make very good points here. Many moons ago, I was looking to
replace bugsnet with a managed, powerful solutions. There were not much.

These days there many very very good ones, custom flows, statuses, link to
emails,  private sections or tickets.  I would suggest to look into this
instead (f.e. I am a big fan of clickup ;).


best,

Andreas Heigl

5 years ago

Hey folks:

Am 09.05.21 um 09:33 schrieb Stanislav Malyshev:

> Hi!
>

[...]

>
> 1. Bug reporting templates> 2. Pre-filter on reported bugs> 3. Advanced search
> 4. Custom fields like PHP version or CVE ID
> 5. Private bugs that are accessible only to members of security team
> 6. Custom statuses (I guess can be worked around with labels, but would
> require a lot of work to make it convenient to use, default screen would
> be pretty much unusable due to clutter, as it only understands closed/open)
> 7. Ability for anybody to submit a bug without opening github account
> (yes, I know it also produces the spam problem) and assigning bugs to
> people that don't have github account (we still can accept patches from
> those, can't we?).
> 8. Statistics
>
>> It may be over optimistic, but we might get better engagement with
>> bugs on github than anywhere else also - Github is where people are
>> tending to do their business today.
>
> I think it's way to generic statement. Some people choose github for
> doing some stuff would be more accurate. I don't think I can remember
> from the top of my head any major project that uses Github as their main
> bug tracker. Maybe they exist, but I certainly can't recall any.
>
>> Github is maintained, hosted, developed, and free, and while it isn't
>> the perfect tool for the job, nothing else is either. We could spend
>> time (which we don't have) developing bugsnet, or installing some
>> other solution in a dark corner of the internet, and solve no problems
>> at all, and be burdened with the ongoing maintenance of that solution.
>
> Why we must install it in a dark corner? Maybe we should ask for some
> help from people who are willing to contribute before we decide to scrap
> the whole thing.
>
> Besides that, I am not sure I am feeling that comfortable with moving
> 100% of the infrastructure of the PHP project to a platform wholly owned
> by Microsoft, and that's where things seem to be heading. I know
> Microsoft is almost not evil now, and it has no problem with PHP
> whatsoever, but things change, and who knows what would happen in
> another 5-10 years. I am not sure hard-binding the whole project to a
> single platform owned by a single company is that great. Due to the
> distributed nature of Git, the repository hosting is very low risk - it
> could be easily moved anywhere. But having the rest of the
> infrastructure in a single point of failure does not feel great. Once we
> move in there, it would be very hard to move out.

This is for me the most interesting point. While it is rather easy to
move fastly away from Github with the source-code it will be much more
complicated to move to "somewhere else" with all of the issues.

Yes, we currently have the same problem with PRs but not "owning" our
bug-report system feels ... not right to me. Especially when there is no
way to actually turning it off due to the security bugs.

While on the other hand I think it absolutely great to have another
infrastructure part that we do not have to maintain!

My prefered way to go would be some other bug-reporting SaaS that can
integrate with github but can provide some more of what we currently
have and that also allows us to also use it for security related issues.

Just my 0.02€

Cheers

Andreas

--
,,,
(o o)
+---------------------------------------------------------ooO-(_)-Ooo-+
| Andreas Heigl                                                       |
| mailto:andreas@heigl.org                  N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org                      https://hei.gl/where |
|                                        https://hei.gl/pubkeyandreas |
+---------------------------------------------------------------------+

Joe Watkins

5 years ago

Hi all,

I shouldn't have said we can "just" move ... I'm not supposing it will be
easy.

We can "just move", in about the same sense that we can "just move" today.

Considering the difficulty of problems we do not currently have is a waste
of time.

Cheers
Joe

On Sun, 9 May 2021 at 10:08, Andreas Heigl <andreas@heigl.org> wrote:

Rowan Collins

5 years ago

On 9 May 2021 08:33:08 BST, Stanislav Malyshev <smalyshev@gmail.com> wrote:

>It is not good that our infrastructure is "hidden away in a dark
>corner", and it is true that bugs needs some TLC for a while. But
>Github
>Issues frankly sucks big time as a bug management system. It's hard to
>fault them as it's not their core business - but while it may be
>adequate for a small project, I don't see how Github system could be
>manageable with any serious volume.

This is my instinct as well - Github Issues seems to be adequate as a lightweight bug tracker, but how well will it scale, and how much will we miss "advanced" features like separately searchable and reportable fields and statuses? Are we better off looking for a SaaS that can provide something more full-featured - Mantis, Phabricator, Trac, Bugzilla, YouTrack, etc?

It would probably be a useful exercise to mock up *how* we would use it - I'm guessing there'd be a long list of custom tags, since that's pretty much the only thing you can use for organising issues. I've seen some projects use prefixed tags like "01 - Component: XML" to simulate a hierarchy.

At a glance, it seems we get as many as 100 non-spam bugs a month, so even if we don't migrate anything, we're potentially into the thousands within a couple of years. Can we do a throwaway import of a few hundred bugs to a test repo, and see what that might look like?

Regards,

--
Rowan Tommins
[IMSoP]

Max Semenik

5 years ago

On Sun, May 9, 2021 at 11:58 AM Rowan Tommins <rowan.collins@gmail.com>
wrote:

> This is my instinct as well - Github Issues seems to be adequate as a
> lightweight bug tracker, but how well will it scale, and how much will we
> miss "advanced" features like separately searchable and reportable fields
> and statuses?

Lots of large projects use GitHub for bug tracking: Go, Rust, Kubernetes -
seems to work well enough for them.

> Are we better off looking for a SaaS that can provide something more
> full-featured - Mantis, Phabricator, Trac, Bugzilla, YouTrack, etc?
>

Half of these (Mantis, Trac and especially Bugzilla) are already obsolete,
migrating to either of them wouldn't be future-proof. If some people here
doubt the future of GitHub, probably only Atlassian or JetBrains SaaS
solutions can be assumed to be on the same order of magnitude of longevity
as GH.

--
Best regards,
Max Semenik

Rowan Collins

5 years ago

On 09/05/2021 16:30, Max Semenik wrote:

> Lots of large projects use GitHub for bug tracking: Go, Rust,
> Kubernetes - seems to work well enough for them.

Those three look like good examples in terms of volume. It's hard to
tell from the outside if people are happy with their processes, but we
can get some idea of what those processes are, and whether PHP could do
something similar.

In terms of "SaaS vs custom code", it's notable that all three run
custom bots to add functionality not offered by Github, with both
automatic actions (e.g. adding default labels, closing stale issues) and
interactive ones (e.g. adding certain labels at user request, without
the user needing permission in Github itself). Rust's bot is strongly
integrated with their Zulip chat instance; Kubernetes' bot is part of
the Prow CI application.

- https://github.com/golang/build/blob/master/cmd/gopherbot/gopherbot.go
- https://github.com/rust-lang/triagebot
- https://github.com/kubernetes/test-infra/tree/master/prow#bots-home

Go makes heavy use of Milestones; my impression is that these are
assigned by Google employees working on the project full time.

Kubernetes and Rust both use prefixed labels for various attributes of
the issue (Area, Status, Severity, etc): Kubernetes has a total of 196;
Rust has a whopping 376, the best description I found of which is this:
https://internals.rust-lang.org/t/how-the-rust-issue-tracker-works/3951

It might just be an illusion, but it feels like all three projects have
a lot more resources to spend on all this than PHP does; Rust has
"Working Groups", Kubernetes has "Special Interest Groups", and PHP
struggles to assign each module a single maintainer. How that affects
our tooling requirements, I'm not sure, but I suspect new contributor
experience should be high on our priority list, either in terms of user
interface or just documentation.

Regards,

--
Rowan Tommins
[IMSoP]

Stas Malyshev

5 years ago

Hi!

> It might just be an illusion, but it feels like all three projects have
> a lot more resources to spend on all this than PHP does; Rust has
> "Working Groups", Kubernetes has "Special Interest Groups", and PHP
> struggles to assign each module a single maintainer. How that affects
> our tooling requirements, I'm not sure, but I suspect new contributor
> experience should be high on our priority list, either in terms of user
> interface or just documentation.

Great survey. I do not have much experience with others, but from my
observations about Prow it's a software system of its own which needs
its own configuration, setup, maintenance, and everything else that's
involved in setting up and maintaining CI/CD system. Github provides a
nice GUI for it but there's much more that is happening behind the
scenes than the GUI. Prow itself is pretty nice to use, once you learn
how to work with it, but we need to be aware that if we want something
with Prow capabilities, we'd need somebody willing to support this
system, so we're back to the same place we departed from.

--
Stas Malyshev
smalyshev@gmail.com

Dan Ackroyd

5 years ago

Hi Joe,

> We have a spam problem on bugsnet

I would snarkily say "maybe accept the PRs from people wanting to work
on it?", but I realise that ignores the underlying problem, that PHP
lacks people. And particularly lacks people who can dedicate time to
understanding, reviewing and saying no to things.

Even if the plan is to move to a different platform, I'd like to take
the time to document what is lacking about bugs.php.net currently.
Please can someone turn on issues for php/web-bugs?

My two concerns with moving to using other systems would be:

* it'd be really useful to be able to authenticate php.net account
holders on other systems, rather than having to set everyone's
permissions up on each system by hand. I believe Saif may have been
thinking about this a bit.

* the low barrier to 'chipping in' through github issues and PRs have
not been a joyous occasion for me. There is a really high proportion
of "non-productive" contributions e.g. people 'approving PRs' for
libraries they are not involved with, or flaming other users. Although
moving to github issues will solve some annoying problems, that might
be balanced by a larger number of slightly less annoying problems.

But sure, the current situation is rubbish and moving issue tracking
to github seems at least worth trying.

Rowan Tommins wrote:

> In terms of "SaaS vs custom code", it's notable that all three run
> custom bots to add functionality not offered by Github,

Yeah, unfortunately Github has focused more on making the barrier to
using Github low, rather than making it easy to implement access
control for non-enterprise customers.

> It might just be an illusion, but it feels like all three projects have
> a lot more resources to spend on all this than PHP does;

I know for various reasons PHP doesn't have a foundation behind it,
but if there was one, it's the boring stuff that a foundation should
be looking at doing:

* maintaining and improving infrastructure.
* writing documentation and helping people learn PHP internals.
* gathering feedback and summarising it.
* maintaining a list of items that could be worked on.

None of those things are a good fit for being maintained long-term on
an ad-hoc basis.

cheers
Dan
Ack

Nikita Popov

5 years ago

On Mon, May 10, 2021 at 3:29 PM Dan Ackroyd <Danack@basereality.com> wrote:

> Hi Joe,
>
> > We have a spam problem on bugsnet
>
> I would snarkily say "maybe accept the PRs from people wanting to work
> on it?", but I realise that ignores the underlying problem, that PHP
> lacks people. And particularly lacks people who can dedicate time to
> understanding, reviewing and saying no to things.
>

Yes, I think this is something people often don't get: It's not just a
matter of finding someone who can implement a change, but also someone who
is willing to review it, and someone who can perform necessary
infrastructure changes, such as server configuration changes or database
migrations. The last part is where things commonly fail.

Even if the plan is to move to a different platform, I'd like to take

> the time to document what is lacking about bugs.php.net currently.
> Please can someone turn on issues for php/web-bugs?
>

Ha, this is a great illustration. You do realize that the bug tracker for
bugs.php.net is bugs.php.net? Under the "General issues - PHP.net Website
problem" category, I believe. However, bugs.php.net is really not suitable
for the kind of use you have in mind. And this also extends to other areas.
For example, for php-src we sometimes use
https://github.com/php/php-tasks/issues to track and coordinate certain
changes, because bugs.php.net is very inconvenient for that purpose.

So, here's my 2c on the proposal. Let me start with issues I see with
bugs.php.net:

* bugs.php.net is regularly semi-down (slow to the point of being
unusable). Either Derick or myself regularly restart the server to recover
it. I don't believe anyone ever looked into the cause.

* There is a lot of linkspam, and it's getting worse. I delete a few
comments ever day. On some days it's just a few, on some days it's dozens.
This is something that *can* likely be addressed, but may degrade user
experience further, e.g. with recaptcha, which is notoriously finicky.

* Next to linkspam, we unfortunately also suffer from hostile user
comments from one Reindl Harald. This user is banned from the mailing list
and our GitHub organization, but we are not able to effectively ban him
from bugs.php.net, because it requires no form of authentication
whatsoever. You can enter an arbitrary email. I think many people don't
appreciate it, but this is actually a ***really big problem***. This user
is consistently and routinely very rude to bug reports, which hurts the
overall reputation of the PHP project. While it should be clear that he
does not represent the PHP project, it still remains a fact that that if
you submit a bug on bugs.php.net, you are quite likely to get some insults
thrown at you. This is not great.

* I think to resolve the previous point (and linkspam as well), we need to
require authentication on bugs.php.net, which would further degrade user
experience. As part of the git.php.net/master.php.net incident response, we
also discussed whether we could move bugs.php.net to authenticate using
GitHub, now that all PHP contributors need to be part of the PHP GitHub
organization. I think if we wanted to retain bugs.php.net, we'd have to
pursue something in this direction, with all users required to authenticate
through GitHub.

* For me personally, as a developer with a php.net account, bugs.php.net
is actually a somewhat okay system. I think the main people suffering from
it are bug reporters not affiliated with php.net. One reason is that
there's no good way to manage your reported bugs -- the only thing you get
is a per-bug (!) password to edit it later, bug you can't track bugs you
reported or similar.

* Bug reports are submitted with incorrect categories very often. I can't
really blame the reporters for that, because there's a *lot* of them, and
they're grouped, so it's really not easy to find the right one (even for
me). This is common to the point that I would consider the inability of the
reporter to specify category/label on GitHub a feature rather than a bug --
this is something that should be done by someone during triage, who is
familiar with the available categories/labels.

* bugs.php.net does not support checkboxes or edits to the bug
description, which makes it completely unsuitable for tracking issues and
any kind of coordination works (this is part of the reason why the
php-tasks tracker exists).

* bugs.php.net does not support labels -- only top-level categorization.
For example, we can't mark bugs as "probably easy" or "good first issue" to
give newbies something to chew on.

GitHub issues address most of these concerns, and are tightly integrated
with the pull request workflow. GitHub issues is not the most advanced bug
tracker out there, but the unfortunate truth is that it's still much better
than bugs.php.net. Some thoughts on how our usage would look like:

* As was already mentioned, there's no support for security issues, so
we'd retain bugs.php.net for that purpose, at least for the time being.

* Categories are translated to labels and applied during triage. As
mentioned before, I believe it's advantageous that the triager adds them
and not the reporter. Our inflow of new bugs is also low enough that I
don't think triage would be an undue burden. The labels could be fairly
similar to the current categories (mostly one per extension), though we
also have a good bit more flexibility, because we are not limited by a
single category per issue. An issue can be both ext-gmp and buildsystem for
a build-system issue in ext/gmp, not just one of them.

* It's worth noting that issues are per-repository, which means that
documentation issues will now live in the doc repo(s), and PECL issues in
the PECL repos. php-src will only have issues relating to php-src
specifically. This is great.

* The minimum minor PHP version affected should probably also be specified
through a label -- I don't personally search issues by version, but other
people (cmb?) might. If search by version is not common, we can have this
information only in the issue description. The operating system can be a
label as well, though we should only add that if the issue is actually
OS-specific -- this is pretty rare.

* One somewhat annoying GitHub limitation is that "saved replies" are
per-account, not per-repo or per-organization. This means that someone
doing a lot of bug triage would have to explicitly configure these. (I
personally don't use the canned replies on bugs.php.net, but I know other
people do.)

* I don't think any other functionality provided by bugs.php.net is
useful, in particular:
a) I pretty much never look at bug votes -- though GitHub has thumbs-up,
thumbs-down as an equivalent there.
b) I have not once made use of the "Reproduced - Same Version - Same OS"
information.
c) Pull request association is handled automatically by GitHub.
d) Patch upload is no longer supported -- this is great. We should
probably disable that even if we keep bugs.php.net, because patches
submitted as anything but pull requests are almost certainly going to get
ignored.
e) Did I miss anything else that bugs.php.net does?

Finally, switching to GitHub issues makes the bug tracker more
user-friendly. This will likely result in a larger number of reports, both
legitimate and bogus. Previous comments focussed on the downside of that
(we will need to close more support-style tickets), but there's also the
upside that it's easier to get people involved with PHP. PHP has something
of a reputation of being unapproachable to new contributors, and the bug
tracker is one part of that (the other parts being the internals mailing
list and the codebase :P)

TL;DR Yes, I do think switching from bugs.php.net to GitHub issues would be
beneficial for the project. Details on how to do that need to be ironed
out, but I think the direction is the right one.

Regards,
Nikita

Rowan Collins

5 years ago

On 10/05/2021 16:10, Nikita Popov wrote:

> Did I miss anything else that bugs.php.net <http://bugs.php.net> does?

The biggest difference I see between GH Issues and every other issue
tracker I've ever seen is pre-defined fields. Labels can broadly do the
same job, but they feel very different when managing them, composing
search queries, and viewing search results.

The fields on the Advanced Search for bugs.php.net are currently:

* Status - GH has only "Open" and "Closed"; we'd probably want a set of
"Status-..." labels
* Type - "Feature Request" is probably fine as a label; "Documentation
Problem" would probably be the doc-en issue tracker, but I don't know
how easily issues can be moved from one project to another during triage
* Project - PHP or PECL; again, possible requirement to move issues
between projects?
* Package - as you say, this is a long and unwieldy list right now, but
one that needs to exist in some form (i.e. re-organizing it to a smaller
list is somewhat orthogonal to moving to a different platform)
* OS - makes sense as optional labels for "Windows-specific" etc
* PHP Version - as you mention, what to do with this depends how people
use it (and also how reliable it is)
* CVE-ID - irrelevant if security issues are going somewhere else
* Assigned - exists in Github!
* Author email - exists in Github!
* Has patch - redundant
* Has pull request - not sure if you can search on this in Github, or if
we'd have to add a manual label (again, this is the kind of thing a lot
of projects maintain bots for)
* Commented by - exists in Github!


Regards,

--
Rowan Tommins
[IMSoP]

Christoph Becker

5 years ago

On 10.05.2021 at 17:10, Nikita Popov wrote:

>  * As was already mentioned, there's no support for security issues, so
> we'd retain bugs.php.net for that purpose, at least for the time being.

But even if bugsnet would no longer be required to file any new tickets,
please keep it in read-only mode.

>  * It's worth noting that issues are per-repository, which means that
> documentation issues will now live in the doc repo(s), and PECL issues in
> the PECL repos. php-src will only have issues relating to php-src
> specifically. This is great.

ACK.

>  * The minimum minor PHP version affected should probably also be specified
> through a label -- I don't personally search issues by version, but other
> people (cmb?) might. If search by version is not common, we can have this
> information only in the issue description. The operating system can be a
> label as well, though we should only add that if the issue is actually
> OS-specific -- this is pretty rare.

I rarely search by version; I think I did that as RM during the
pre-release phase of 7.3.  Most often the version info is pretty
irrelevant, since the issue affects all supported PHP versions.  In my
opinion, having the PHP version in the bug description is good enough
for now; we still can add labels if that turns out to be useful.

>   a) I pretty much never look at bug votes -- though GitHub has thumbs-up,
> thumbs-down as an equivalent there.

I would actually prefer the GH reactions.  The voting feature might
still be broken, anyway.

> TL;DR Yes, I do think switching from bugs.php.net to GitHub issues would be
> beneficial for the project. Details on how to do that need to be ironed
> out, but I think the direction is the right one.

I'm +0.5 on this.

--
Christoph M. Becker

Nikita Popov

5 years ago

On Mon, May 10, 2021 at 11:22 PM Christoph M. Becker <cmbecker69@gmx.de>
wrote:

> On 10.05.2021 at 17:10, Nikita Popov wrote:
>
> >  * As was already mentioned, there's no support for security issues, so
> > we'd retain bugs.php.net for that purpose, at least for the time being.
>
> But even if bugsnet would no longer be required to file any new tickets,
> please keep it in read-only mode.
>
> >  * It's worth noting that issues are per-repository, which means that
> > documentation issues will now live in the doc repo(s), and PECL issues in
> > the PECL repos. php-src will only have issues relating to php-src
> > specifically. This is great.
>
> ACK.
>
> >  * The minimum minor PHP version affected should probably also be
> specified
> > through a label -- I don't personally search issues by version, but other
> > people (cmb?) might. If search by version is not common, we can have this
> > information only in the issue description. The operating system can be a
> > label as well, though we should only add that if the issue is actually
> > OS-specific -- this is pretty rare.
>
> I rarely search by version; I think I did that as RM during the
> pre-release phase of 7.3.  Most often the version info is pretty
> irrelevant, since the issue affects all supported PHP versions.  In my
> opinion, having the PHP version in the bug description is good enough
> for now; we still can add labels if that turns out to be useful.
>
> >   a) I pretty much never look at bug votes -- though GitHub has
> thumbs-up,
> > thumbs-down as an equivalent there.
>
> I would actually prefer the GH reactions.  The voting feature might
> still be broken, anyway.
>
> > TL;DR Yes, I do think switching from bugs.php.net to GitHub issues
> would be
> > beneficial for the project. Details on how to do that need to be ironed
> > out, but I think the direction is the right one.
>
> I'm +0.5 on this.

To make some forward progress here, I think a good starting point would be
to enable GitHub issues on the doc-* repos to get some usage experience in
a more limited setting. Docs issues probably benefit more from being hosted
on GitHub than php-src issues, as this is an area where 3rd-party
contributors can easily pick up issues they can address.

If all goes well, we can disable submission of "Documentation Problem" bugs
in bugsnet and consider how to move forward with php-src.

Regards,
Nikita

Christoph Becker

5 years ago

On 25.05.2021 at 14:57, Nikita Popov wrote:

> To make some forward progress here, I think a good starting point would be
> to enable GitHub issues on the doc-* repos to get some usage experience in
> a more limited setting. Docs issues probably benefit more from being hosted
> on GitHub than php-src issues, as this is an area where 3rd-party
> contributors can easily pick up issues they can address.

Agreed (maybe start with doc-en only for now; there are not that many
translation issues anyway).  Feel free to open the issues right away.

> If all goes well, we can disable submission of "Documentation Problem" bugs
> in bugsnet and consider how to move forward with php-src.

One particular problem would be issues filed as bug, but are
reclassified as doc problem.  We likely would need a bot to "transfer"
these issues to doc-en.

Christoph

Max Semenik

5 years ago

On Sun, May 9, 2021 at 11:58 AM Rowan Tommins <rowan.collins@gmail.com>
wrote:

> Can we do a throwaway import of a few hundred bugs to a test repo, and see
> what that might look like?

Is there a dump of public issues available somewhere?

The closest to sufficient data export I can find is e.g.
https://bugs.php.net/rss/bug.php?id=70549&format=xml but it lacks comments
even though the code is supposed to include them too.

--
Best regards,
Max Semenik

Mike Schinkel

5 years ago

> On May 9, 2021, at 4:58 AM, Rowan Tommins <rowan.collins@gmail.com> wrote:
>
> On 9 May 2021 08:33:08 BST, Stanislav Malyshev <smalyshev@gmail.com> wrote:
>> It is not good that our infrastructure is "hidden away in a dark
>> corner", and it is true that bugs needs some TLC for a while. But
>> Github
>> Issues frankly sucks big time as a bug management system. It's hard to
>> fault them as it's not their core business - but while it may be
>> adequate for a small project, I don't see how Github system could be
>> manageable with any serious volume.
>
>
> This is my instinct as well - Github Issues seems to be adequate as a lightweight bug tracker, but how well will it scale, and how much will we miss "advanced" features like separately searchable and reportable fields and statuses? Are we better off looking for a SaaS that can provide something more full-featured - Mantis, Phabricator, Trac, Bugzilla, YouTrack, etc?

Possibly the best of both worlds:

https://github.com/marketplace/zube <https://github.com/marketplace/zube>
https://github.com/marketplace/skope-github-issue-tracker <https://github.com/marketplace/skope-github-issue-tracker>
https://github.com/marketplace/orwell-app <https://github.com/marketplace/orwell-app>
https://github.com/marketplace/codetree <https://github.com/marketplace/codetree>

Plus another 545 PM-related apps and actions to fill in those "advanced" features that are missing from the Github tracker:

https://github.com/marketplace/category/project-management <https://github.com/marketplace/category/project-management>

And this list should only get better over time.

And for any functionality missing, there are always these:

https://github.com/KnpLabs/php-github-api <https://github.com/KnpLabs/php-github-api>
https://github.com/googleapis/google-api-php-client <https://github.com/googleapis/google-api-php-client>
https://github.com/mpscholten/github-api <https://github.com/mpscholten/github-api>
https://github.com/googleapis/google-api-php-client-services <https://github.com/googleapis/google-api-php-client-services>


Rhetorical question: What developer today does not have experience with Github issues?  Not so for many (any?) others.

Github issues FTW!  IMO, anyway. :-)

-Mike

André Hänsel

5 years ago

You're talking about bugs.php.net, right? If you decide to move it, please leave the old one online in readonly mode. It's a valuable documentation resource.

Larry Garfield

5 years ago

On Sun, May 9, 2021, at 1:48 AM, Joe Watkins wrote:

> Morning internals,
>
> We have a spam problem on bugsnet, it's not a new problem. Nikita had to
> waste time deleting 20 odd messages from bugsnet yesterday and this is a
> common, daily occurrence. We clearly don't have time for this.
>
> Quite aside from spam problems, bugsnet is hidden away in a dark corner of
> the internet that requires a special login, doesn't integrate with source
> code or our current workflow (very nicely), and doesn't get updated or
> developed.
>
> Having moved our workflow to github, now seems to be the time to seriously
> consider retiring bugsnet for general use, and using the tools that are
> waiting for us - Github Issues.
>
> I'm aware that bugsnet serves as the disclosure method for security bugs
> and github doesn't have a solution to that. Leaving that to one side for
> now ...
>
> I'm also aware that bugsnet carries with it 20 years worth of crusty old
> feature requests and bugs, that are never realistically going to be dealt
> with. In the past I've spent time trying to close very old bugs that no
> longer seem relevant, the fact is that there are so many of these that I
> don't think I made a dent.
>
> It seems obvious that we don't want to migrate all of the data on bugsnet,
> but nor do we want to loose the most recent and relevant reports.
>
> I propose that we disable bugsnet for all but security issues leaving
> responsible disclosure method to be handled in some other way at a later
> date. Leaving bugsnet in a (mostly) readonly mode.
>
> We then send a notification to all bugs that were opened against a specific
> and supported version of PHP, notifying the opener of the change and
> requesting that they take a couple of minutes to open their issue on github.
>
> I think we might get quite a good response here - anyone suffering the
> worst consequences of bugs - production servers can't be upgraded and so on
> - are already waiting for a notification from bugsnet, I'm sure the
> majority of them will do as we ask.
>
> In some set number of weeks (to be decided), and depending on the response
> to our switching over to github, we can try to determine at that time if
> it's worth trying to import any data from bugsnet. We can also consider at
> this time when it might be appropriate to retire bugsnet entirely.
>
> We will not be free of spam simply by moving, but github has the tools we
> need to moderate the content properly - you can block people. In addition,
> I feel people are less likely to misbehave if they think their co-workers
> or employers might be able to see what they are doing, which may have an
> effect also.
>
> It may be over optimistic, but we might get better engagement with bugs on
> github than anywhere else also - Github is where people are tending to do
> their business today.
>
> Github is maintained, hosted, developed, and free, and while it isn't the
> perfect tool for the job, nothing else is either. We could spend time
> (which we don't have) developing bugsnet, or installing some other solution
> in a dark corner of the internet, and solve no problems at all, and be
> burdened with the ongoing maintenance of that solution.
>
> The people who have to spend the most time on this are release managers,
> and so while I'm talking to everyone, it is release managers opinions that
> I'm most interested in, they are the people who will be and have been most
> effected by the shortcomings in bugsnet, whose opinions are most relevant
> in this space.
>
> I don't think a vote is appropriate, this decision should be made by the
> people whose "jobs" are directly effected - with input from the community,
> of course. Not least of all, it will take a month to close a vote, by which
> time we will have wasted another (working) day or more of Nikitas time.
> Having said all that, I am looking for a consensus before we take any
> action. My arm can be twisted, but this is my current position and I think
> it's a reasonable one.
>
> On the issue of responsible disclosure ... we can treat this separately,
> with the recent change in the workflow, this process is in need of review
> anyway. How that is handled should be decided by the people who have a hand
> in that process, and so it seems prudent to leave it aside for now.
>
> Cheers
> Joe

I agree with Joe that this is a decision that should be made mainly by the release managers, very-high-level contributors (Nikita, Dmitry, etc.), and whatever passes for sysadmins around here. :-)  As a fan of decoupling, however, I want to note that it sounds like there's a couple of separate issues involved here, for which GitHub is one possible solution.

Problem: The current system has a spam problem.
GitHub answer: GitHub has better anti-spam tools.
Alternatives/limitations: There are undoubtedly other tools that also have way better anti-spam tools, both SaaS and self-hosted.

Problem: No one can find the bloody thing.
GitHub answer: 99% of devs already have a GitHub account at this point, for better or worse.
Alternatives/limitations: If visibility is the goal, making bugs.php.net more visible/accessible/easy to find isn't that big of a lift.  It's just a matter of adding better links on the main site.

Problem: The current bugsite has decades of useless issues on it, it's time to declare bankruptcy.
GitHub answer: Migrating to a new system is a good opportunity to purge old issues.
Alternatives/limitations: Migrating GitLab, self-hosted GitLab, YouTrack, Bugzilla, or any other tool would offer a similar `rf -rf` opportunity.  But no matter where we move, the same pile of old issues is going to reappear anyway over time.  That's inevitable.  And an `rm -rf` on any open issues that are not against a currently supported version is (I imagine) just an SQL query away on the current site.  I'd say this is the weakest argument.  (And a hosted service would probably have less ability to periodically declare bankruptcy.  I don't know now to do that on GitHub, honestly.)

Problem: Bugsnet is a thing we have to host ourselves, and we know how good PHP is at that...
GitHub answer: Hosted, not our problem.
Alternatives/limitations: This would be equally-well resolved by using any SaaS; GitHub, GitLab, YouTrack, YouNameit.

Problem: The software is old and busted.
GitHub answer: Always maintained by MS.
Alternatives/limitations: An alternative self-hosted tool that's actually updated regularly, such as self-hosted GitLab, would be a partial answer, while still leaving us "in control".  Whether we'd have the same customizability will depend on the tool.

Problem: Having the bug list and code hosting in different places is weird and confusing.
GitHub answer: So give them all to us!
Alternatives/limitations: There are other code-and-issue tools (eg, GitLab) that would also allow for co-locating everything, either hosted or local.  As noted, moving the code from GitHub to another Git service is quite straightforward.  GitHub only has an advantage here because of its popularity and because that's where the code moved to after the server hack.  Also, there's probably an argument to be made that keeping those tools separate has its advantages, though I wouldn't make that argument myself.

I have no skin in this game and can roll with whatever, most likely.  I just want to make sure the lay of the land is clear, and there's a clear picture of the options available.  "Move to GitHub" is always a viable answer to avoiding self-hosted monstrosities, but there are also alternatives that would address many, perhaps all, of the same issues, and raise fewer issues of their own.  (No tool would have no issues.)

--Larry Garfield

Levi Morrison

5 years ago

On Sun, May 9, 2021 at 8:26 AM Larry Garfield <larry@garfieldtech.com> wrote:

>
> On Sun, May 9, 2021, at 1:48 AM, Joe Watkins wrote:
> > Morning internals,
> >
> > We have a spam problem on bugsnet, it's not a new problem. Nikita had to
> > waste time deleting 20 odd messages from bugsnet yesterday and this is a
> > common, daily occurrence. We clearly don't have time for this.
> >
> > Quite aside from spam problems, bugsnet is hidden away in a dark corner of
> > the internet that requires a special login, doesn't integrate with source
> > code or our current workflow (very nicely), and doesn't get updated or
> > developed.
> >
> > Having moved our workflow to github, now seems to be the time to seriously
> > consider retiring bugsnet for general use, and using the tools that are
> > waiting for us - Github Issues.
> >
> > I'm aware that bugsnet serves as the disclosure method for security bugs
> > and github doesn't have a solution to that. Leaving that to one side for
> > now ...
> >
> > I'm also aware that bugsnet carries with it 20 years worth of crusty old
> > feature requests and bugs, that are never realistically going to be dealt
> > with. In the past I've spent time trying to close very old bugs that no
> > longer seem relevant, the fact is that there are so many of these that I
> > don't think I made a dent.
> >
> > It seems obvious that we don't want to migrate all of the data on bugsnet,
> > but nor do we want to loose the most recent and relevant reports.
> >
> > I propose that we disable bugsnet for all but security issues leaving
> > responsible disclosure method to be handled in some other way at a later
> > date. Leaving bugsnet in a (mostly) readonly mode.
> >
> > We then send a notification to all bugs that were opened against a specific
> > and supported version of PHP, notifying the opener of the change and
> > requesting that they take a couple of minutes to open their issue on github.
> >
> > I think we might get quite a good response here - anyone suffering the
> > worst consequences of bugs - production servers can't be upgraded and so on
> > - are already waiting for a notification from bugsnet, I'm sure the
> > majority of them will do as we ask.
> >
> > In some set number of weeks (to be decided), and depending on the response
> > to our switching over to github, we can try to determine at that time if
> > it's worth trying to import any data from bugsnet. We can also consider at
> > this time when it might be appropriate to retire bugsnet entirely.
> >
> > We will not be free of spam simply by moving, but github has the tools we
> > need to moderate the content properly - you can block people. In addition,
> > I feel people are less likely to misbehave if they think their co-workers
> > or employers might be able to see what they are doing, which may have an
> > effect also.
> >
> > It may be over optimistic, but we might get better engagement with bugs on
> > github than anywhere else also - Github is where people are tending to do
> > their business today.
> >
> > Github is maintained, hosted, developed, and free, and while it isn't the
> > perfect tool for the job, nothing else is either. We could spend time
> > (which we don't have) developing bugsnet, or installing some other solution
> > in a dark corner of the internet, and solve no problems at all, and be
> > burdened with the ongoing maintenance of that solution.
> >
> > The people who have to spend the most time on this are release managers,
> > and so while I'm talking to everyone, it is release managers opinions that
> > I'm most interested in, they are the people who will be and have been most
> > effected by the shortcomings in bugsnet, whose opinions are most relevant
> > in this space.
> >
> > I don't think a vote is appropriate, this decision should be made by the
> > people whose "jobs" are directly effected - with input from the community,
> > of course. Not least of all, it will take a month to close a vote, by which
> > time we will have wasted another (working) day or more of Nikitas time.
> > Having said all that, I am looking for a consensus before we take any
> > action. My arm can be twisted, but this is my current position and I think
> > it's a reasonable one.
> >
> > On the issue of responsible disclosure ... we can treat this separately,
> > with the recent change in the workflow, this process is in need of review
> > anyway. How that is handled should be decided by the people who have a hand
> > in that process, and so it seems prudent to leave it aside for now.
> >
> > Cheers
> > Joe
>
> I agree with Joe that this is a decision that should be made mainly by the release managers, very-high-level contributors (Nikita, Dmitry, etc.), and whatever passes for sysadmins around here. :-)  As a fan of decoupling, however, I want to note that it sounds like there's a couple of separate issues involved here, for which GitHub is one possible solution.
>
> Problem: The current system has a spam problem.
> GitHub answer: GitHub has better anti-spam tools.
> Alternatives/limitations: There are undoubtedly other tools that also have way better anti-spam tools, both SaaS and self-hosted.
>
> Problem: No one can find the bloody thing.
> GitHub answer: 99% of devs already have a GitHub account at this point, for better or worse.
> Alternatives/limitations: If visibility is the goal, making bugs.php.net more visible/accessible/easy to find isn't that big of a lift.  It's just a matter of adding better links on the main site.
>
> Problem: The current bugsite has decades of useless issues on it, it's time to declare bankruptcy.
> GitHub answer: Migrating to a new system is a good opportunity to purge old issues.
> Alternatives/limitations: Migrating GitLab, self-hosted GitLab, YouTrack, Bugzilla, or any other tool would offer a similar `rf -rf` opportunity.  But no matter where we move, the same pile of old issues is going to reappear anyway over time.  That's inevitable.  And an `rm -rf` on any open issues that are not against a currently supported version is (I imagine) just an SQL query away on the current site.  I'd say this is the weakest argument.  (And a hosted service would probably have less ability to periodically declare bankruptcy.  I don't know now to do that on GitHub, honestly.)
>
> Problem: Bugsnet is a thing we have to host ourselves, and we know how good PHP is at that...
> GitHub answer: Hosted, not our problem.
> Alternatives/limitations: This would be equally-well resolved by using any SaaS; GitHub, GitLab, YouTrack, YouNameit.
>
> Problem: The software is old and busted.
> GitHub answer: Always maintained by MS.
> Alternatives/limitations: An alternative self-hosted tool that's actually updated regularly, such as self-hosted GitLab, would be a partial answer, while still leaving us "in control".  Whether we'd have the same customizability will depend on the tool.
>
> Problem: Having the bug list and code hosting in different places is weird and confusing.
> GitHub answer: So give them all to us!
> Alternatives/limitations: There are other code-and-issue tools (eg, GitLab) that would also allow for co-locating everything, either hosted or local.  As noted, moving the code from GitHub to another Git service is quite straightforward.  GitHub only has an advantage here because of its popularity and because that's where the code moved to after the server hack.  Also, there's probably an argument to be made that keeping those tools separate has its advantages, though I wouldn't make that argument myself.
>
> I have no skin in this game and can roll with whatever, most likely.  I just want to make sure the lay of the land is clear, and there's a clear picture of the options available.  "Move to GitHub" is always a viable answer to avoiding self-hosted monstrosities, but there are also alternatives that would address many, perhaps all, of the same issues, and raise fewer issues of their own.  (No tool would have no issues.)
>
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php

I think GitLab could be a feasible solution. The product is open
source, so we can theoretically migrate if the hosted GitLab goes
away. Realistically, if the hosted GitLab goes away I think we're
going to have problems anyway, but the point is that this part of the
story is different from GitHub's, while providing similar services. As
for cost, it's free and they seem to have an offering specifically for
free, open-source software projects for which we might qualify:
https://about.gitlab.com/solutions/open-source/

For the record, I am also fine with moving to GitHub.

Jakub Zelenka

5 years ago

Hi,

> Having moved our workflow to github, now seems to be the time to seriously
> consider retiring bugsnet for general use, and using the tools that are
> waiting for us - Github Issues.
>

+1, I have been dealing with bugsnet quite a bit as part of maintaining
openssl ext and FPM and it really sucks. Github issues are much better from
the maintainer point of view.

> I'm aware that bugsnet serves as the disclosure method for security bugs
> and github doesn't have a solution to that. Leaving that to one side for
> now ...
>

NodeJS uses hackerone which has got free plans for open source so that
might be an option. I'm sure there are more options and we don't have to
keep bugsnet for that too. But agree that starting with normal bugs and
requests is a way to go.

> I'm also aware that bugsnet carries with it 20 years worth of crusty old
> feature requests and bugs, that are never realistically going to be dealt
> with. In the past I've spent time trying to close very old bugs that no
> longer seem relevant, the fact is that there are so many of these that I
> don't think I made a dent.
>

Lots of them are still valid though. At least the ones for openssl and fpm
that I track. It's not completely true that they are not going to be dealt
with. For example just recently Christoph made a PR for pkcs7 issue
reported in 2005 and I'm looking to the way how to write a test for it.
Just want to say that those are still valid and we will likely need some
kind of migration for many of those bugs even though OP is not active. It
could be just a tool that maintainers can use for selected bugs. I guess
just having some export in json for each bug would be great. Then the tool
to create a new issue and comments in gh would be easy - I could even write
it myself.. :)

> It seems obvious that we don't want to migrate all of the data on bugsnet,
> but nor do we want to loose the most recent and relevant reports.
>
> I propose that we disable bugsnet for all but security issues leaving
> responsible disclosure method to be handled in some other way at a later
> date. Leaving bugsnet in a (mostly) readonly mode.
>

Could we just leave it editable for VCS users only? That would help with
tracking and closing the migrated issues. It would eliminate spam so it
should be fine to keep it like that for some time.

Cheers

Jakub

Wim Godden

5 years ago

On 9/05/2021 8:48, Joe Watkins wrote:

> I'm aware that bugsnet serves as the disclosure method for security bugs
> and github doesn't have a solution to that. Leaving that to one side for
> now ...

Just want to weigh in on this item (also mentioned by Stanislav as an
important issue). Although Github doesn't provide a way to submit
security issues in a private way, there is a way to send people in the
right direction for security disclosures. For a simple example :
https://github.com/dask/dask-gateway/issues/new/choose where you can see
the 3rd item can point to a separate URL explaining how to report
security issues. These could either still be submitted to the
bugs.php.net or could use a very simple captcha-enabled form (for
anti-spam) that sends the report to specific people.

Kind regards,

Wim

Benjamin Eberlei

5 years ago

On Sun, May 9, 2021 at 8:49 AM Joe Watkins <krakjoe@php.net> wrote:

> Morning internals,
>
> We have a spam problem on bugsnet, it's not a new problem. Nikita had to
> waste time deleting 20 odd messages from bugsnet yesterday and this is a
> common, daily occurrence. We clearly don't have time for this.
>
> Quite aside from spam problems, bugsnet is hidden away in a dark corner of
> the internet that requires a special login, doesn't integrate with source
> code or our current workflow (very nicely), and doesn't get updated or
> developed.
>
> Having moved our workflow to github, now seems to be the time to seriously
> consider retiring bugsnet for general use, and using the tools that are
> waiting for us - Github Issues.
>
> I'm aware that bugsnet serves as the disclosure method for security bugs
> and github doesn't have a solution to that. Leaving that to one side for
> now ...
>
> I'm also aware that bugsnet carries with it 20 years worth of crusty old
> feature requests and bugs, that are never realistically going to be dealt
> with. In the past I've spent time trying to close very old bugs that no
> longer seem relevant, the fact is that there are so many of these that I
> don't think I made a dent.
>
> It seems obvious that we don't want to migrate all of the data on bugsnet,
> but nor do we want to loose the most recent and relevant reports.
>
> I propose that we disable bugsnet for all but security issues leaving
> responsible disclosure method to be handled in some other way at a later
> date. Leaving bugsnet in a (mostly) readonly mode.
>
> We then send a notification to all bugs that were opened against a specific
> and supported version of PHP, notifying the opener of the change and
> requesting that they take a couple of minutes to open their issue on
> github.
>
> I think we might get quite a good response here - anyone suffering the
> worst consequences of bugs - production servers can't be upgraded and so on
> - are already waiting for a notification from bugsnet, I'm sure the
> majority of them will do as we ask.
>
> In some set number of weeks (to be decided), and depending on the response
> to our switching over to github, we can try to determine at that time if
> it's worth trying to import any data from bugsnet. We can also consider at
> this time when it might be appropriate to retire bugsnet entirely.
>
> We will not be free of spam simply by moving, but github has the tools we
> need to moderate the content properly - you can block people. In addition,
> I feel people are less likely to misbehave if they think their co-workers
> or employers might be able to see what they are doing, which may have an
> effect also.
>
> It may be over optimistic, but we might get better engagement with bugs on
> github than anywhere else also - Github is where people are tending to do
> their business today.
>

One downside of this "easy access" is that Github Issues tend to get used
as support question forum, at least from my experience on Doctrine it can
easily be 50% of the issues that are support questions. This is much more
work to process than simple spam issues, because there is a human on the
other side who need to be directed towards the proper support channel.

In addition I agree with Rowans assessment that large projects usually have
lots of automation in place on top of Github issues that we would again
need to configure, write or maintain in one way or another.

bugsweb on the other hand is a "classic LAMP" stack application, so maybe
we could look into removing the infrastructure variable from the hosting
equation and look for a PaaS provider? Spam protection third party services
are also available and might potentially be integrated with in a reasonable
amount of time.

Derick Rethans

5 years ago

Hi Joe,

I don't think anybody denies that bugsnet isn't great, and that spam is
an issue. I would argue that the main reason for the spam is, is that we
don't require a sign-up. But I think we need to be really careful if
we'd decide to move to something else.


TLDR: I don't believe GitHub issues is suitable, neither feature wise or
future-safety wise. We need to be sensible about both items if we
decided to move to a different issue tracker.


Right now, bugs has several features that GitHub issues doesn't provide:
multiple statusses, categories (of which bugsnet has a *lot*), and
dedicated fields for the PHP version etc.

I know that the PHP version can be done through a issue template, and
that the categories can be done with labels. But in order to represent
the same rich category information, and hence be able to search on bugs
in a specific category (such as "DateTime", you'd need a label each for
each current category.

Having to maintain these labels, and setting them correctly on issues,
is perhaps going to be more work than removing spam. I'm sure we can
make it work *somewhat*, but it is going to be a degradation of what
bugsnet does. On top of that, we'll have to install/configure build
automation, such as our "quick closes", or the "closed after 3 weeks of
inactivity".

And I think somebody else mentioned this already, but I am going to
expect that people will use the issue tracker for support questions as
well. It has been the case for every GH repository that I had issues
enabled on.


The other important issue is to consider the continuation of the
availability of the platform. Bugsnet has been running for 23 years.
While that unfortunately means that some of the code is that old, it is
IMO a stellar track record.

Is GitHub Issues going to be around in a way that we want it in another
23 years? And, if GHI is going a way we don't want it to go in in say 5
years, is it possible to switch easily to something else?

This isn't really a problem with the code repository itself, as it's
easy enough to clone and move somewhere else. But that is *not* the case
for GHI. AFAIK, you can't either import or export easily into/out of it,
and most definitely not in the rich format that we currently have in
bugsnet.


I did actually experiment with GitHub Issues for Xdebug, and decided
that even for that small a project, it wasn't really suitable due to the
feature set, and that's basically just *me* using it.

I currently use Mantis, which although it has it's minor issues, works
actually really well. I can host it myself, although they can provide a
hosted service, and it's actively maintained, and written in PHP.



cheers,
Derick

--
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

Unnamed Person

5 years ago

On 09/05/2021 09:48, Joe Watkins wrote:

> Morning internals,
>
> We have a spam problem on bugsnet, it's not a new problem. Nikita had to
> waste time deleting 20 odd messages from bugsnet yesterday and this is a
> common, daily occurrence. We clearly don't have time for this.
>
> Quite aside from spam problems, bugsnet is hidden away in a dark corner of
> the internet that requires a special login, doesn't integrate with source
> code or our current workflow (very nicely), and doesn't get updated or
> developed.

So, there are 2 distinct issues: spam from bugsnet (this one can be
mitigated by replacing current "solve a problem" challenge by something
more sophisticated) and the bugsnet itself being a burden (which can't
be solved quickly).

Let's separate the two: this way we can have kill the spam in the short
term and get enough time to shape out the migration plan if there's a
consensus on the matter.

What about integrating [recaptcha][1] for now? Integration is rather
simple but there are other concerns, e.g. a third-party JS code on the
page that accepts security issues.

If it sounds like a way to go, I can help with the integration. Thanks
to [Dan Ackroyd's pull request][2], setting up environment for torturing
bugsnet locally is a no-brainer.

[1]: https://www.google.com/recaptcha/about/
[2]: https://github.com/php/web-bugs/pull/91

Andreas Heigl

5 years ago

Hey All

Am 10.05.21 um 14:44 schrieb Alexander Kurilo via internals:

> On 09/05/2021 09:48, Joe Watkins wrote:
>> Morning internals,
>>
>> We have a spam problem on bugsnet, it's not a new problem. Nikita had to
>> waste time deleting 20 odd messages from bugsnet yesterday and this is a
>> common, daily occurrence. We clearly don't have time for this.
>>
>> Quite aside from spam problems, bugsnet is hidden away in a dark
>> corner of
>> the internet that requires a special login, doesn't integrate with source
>> code or our current workflow (very nicely), and doesn't get updated or
>> developed.
>
>
> So, there are 2 distinct issues: spam from bugsnet (this one can be
> mitigated by replacing current "solve a problem" challenge by something
> more sophisticated) and the bugsnet itself being a burden (which can't
> be solved quickly).
>
> Let's separate the two: this way we can have kill the spam in the short
> term and get enough time to shape out the migration plan if there's a
> consensus on the matter.
>
> What about integrating [recaptcha][1] for now? Integration is rather
> simple but there are other concerns, e.g. a third-party JS code on the
> page that accepts security issues.

If so, can we please use something else? Implementing a Honeypot or a
simple math-captcha isn't that complicated (and I assume that a person
that can provide a decent bug description can also solve a riddle like
"Enter the result of 7 plus 2")

Thanks!

Andreas

--
,,,
(o o)
+---------------------------------------------------------ooO-(_)-Ooo-+
| Andreas Heigl                                                       |
| mailto:andreas@heigl.org                  N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org                                           |
+---------------------------------------------------------------------+
| https://hei.gl/appointmentwithandreas                               |
+---------------------------------------------------------------------+

Christoph Becker

5 years ago

On 10.05.2021 at 15:39, Andreas Heigl wrote:

> Hey All
>
> Am 10.05.21 um 14:44 schrieb Alexander Kurilo via internals:
>> On 09/05/2021 09:48, Joe Watkins wrote:
>>> Morning internals,
>>>
>>> We have a spam problem on bugsnet, it's not a new problem. Nikita had to
>>> waste time deleting 20 odd messages from bugsnet yesterday and this is a
>>> common, daily occurrence. We clearly don't have time for this.
>>>
>>> Quite aside from spam problems, bugsnet is hidden away in a dark
>>> corner of
>>> the internet that requires a special login, doesn't integrate with source
>>> code or our current workflow (very nicely), and doesn't get updated or
>>> developed.
>>
>>
>> So, there are 2 distinct issues: spam from bugsnet (this one can be
>> mitigated by replacing current "solve a problem" challenge by something
>> more sophisticated) and the bugsnet itself being a burden (which can't
>> be solved quickly).
>>
>> Let's separate the two: this way we can have kill the spam in the short
>> term and get enough time to shape out the migration plan if there's a
>> consensus on the matter.
>>
>> What about integrating [recaptcha][1] for now? Integration is rather
>> simple but there are other concerns, e.g. a third-party JS code on the
>> page that accepts security issues.
>
> If so, can we please use something else? Implementing a Honeypot or a
> simple math-captcha isn't that complicated (and I assume that a person
> that can provide a decent bug description can also solve a riddle like
> "Enter the result of 7 plus 2")

We already have a simple math CAPTCHA; it doesn't work, though, if users
switch browser tabs.  Anyhow, I don't think that a CAPTCHA would be
really helpful; we need some real user authentication; this way we could
also block unwanted users.

--
Christoph M. Becker

Remi Collet

5 years ago

Le 09/05/2021 à 08:48, Joe Watkins a écrit :

> Having moved our workflow to github, now seems to be the time to seriously
> consider retiring bugsnet for general use, and using the tools that are
> waiting for us - Github Issues.

Please NO

This mean we will drop ownership on all data and history about bug.

Remi

Nikita Popov

4 years ago

On Sun, May 9, 2021 at 8:49 AM Joe Watkins <krakjoe@php.net> wrote:

> Morning internals,
>
> We have a spam problem on bugsnet, it's not a new problem. Nikita had to
> waste time deleting 20 odd messages from bugsnet yesterday and this is a
> common, daily occurrence. We clearly don't have time for this.
>
> Quite aside from spam problems, bugsnet is hidden away in a dark corner of
> the internet that requires a special login, doesn't integrate with source
> code or our current workflow (very nicely), and doesn't get updated or
> developed.
>
> Having moved our workflow to github, now seems to be the time to seriously
> consider retiring bugsnet for general use, and using the tools that are
> waiting for us - Github Issues.
>
> I'm aware that bugsnet serves as the disclosure method for security bugs
> and github doesn't have a solution to that. Leaving that to one side for
> now ...
>
> I'm also aware that bugsnet carries with it 20 years worth of crusty old
> feature requests and bugs, that are never realistically going to be dealt
> with. In the past I've spent time trying to close very old bugs that no
> longer seem relevant, the fact is that there are so many of these that I
> don't think I made a dent.
>
> It seems obvious that we don't want to migrate all of the data on bugsnet,
> but nor do we want to loose the most recent and relevant reports.
>
> I propose that we disable bugsnet for all but security issues leaving
> responsible disclosure method to be handled in some other way at a later
> date. Leaving bugsnet in a (mostly) readonly mode.
>
> We then send a notification to all bugs that were opened against a specific
> and supported version of PHP, notifying the opener of the change and
> requesting that they take a couple of minutes to open their issue on
> github.
>
> I think we might get quite a good response here - anyone suffering the
> worst consequences of bugs - production servers can't be upgraded and so on
> - are already waiting for a notification from bugsnet, I'm sure the
> majority of them will do as we ask.
>
> In some set number of weeks (to be decided), and depending on the response
> to our switching over to github, we can try to determine at that time if
> it's worth trying to import any data from bugsnet. We can also consider at
> this time when it might be appropriate to retire bugsnet entirely.
>
> We will not be free of spam simply by moving, but github has the tools we
> need to moderate the content properly - you can block people. In addition,
> I feel people are less likely to misbehave if they think their co-workers
> or employers might be able to see what they are doing, which may have an
> effect also.
>
> It may be over optimistic, but we might get better engagement with bugs on
> github than anywhere else also - Github is where people are tending to do
> their business today.
>
> Github is maintained, hosted, developed, and free, and while it isn't the
> perfect tool for the job, nothing else is either. We could spend time
> (which we don't have) developing bugsnet, or installing some other solution
> in a dark corner of the internet, and solve no problems at all, and be
> burdened with the ongoing maintenance of that solution.
>
> The people who have to spend the most time on this are release managers,
> and so while I'm talking to everyone, it is release managers opinions that
> I'm most interested in, they are the people who will be and have been most
> effected by the shortcomings in bugsnet, whose opinions are most relevant
> in this space.
>
> I don't think a vote is appropriate, this decision should be made by the
> people whose "jobs" are directly effected - with input from the community,
> of course. Not least of all, it will take a month to close a vote, by which
> time we will have wasted another (working) day or more of Nikitas time.
> Having said all that, I am looking for a consensus before we take any
> action. My arm can be twisted, but this is my current position and I think
> it's a reasonable one.
>
> On the issue of responsible disclosure ... we can treat this separately,
> with the recent change in the workflow, this process is in need of review
> anyway. How that is handled should be decided by the people who have a hand
> in that process, and so it seems prudent to leave it aside for now.
>
> Cheers
> Joe
>

To follow up on this proposal: We have been using GitHub Issue for docs for
a while now (https://github.com/php/doc-en/issues) and I'm about to disable
submission of new docs issues on bugs.php.net. I think it's time to switch
non-security bugs for PHP proper as well, for all the reasons that have
already been discussed.

For docs we didn't really do anything special in terms of labels etc. I
think for the php-src repo we do want to introduce some more structure for
categorization and triage, as the volume tends to be higher there.

For that purpose I've created a prototype of how things could look like
here: https://github.com/nikic/test-repo/issues/new/choose Note that
creating a bug report will open a form using the recently introduced issue
form feature.

I'm proposing the following label structure (the list at
https://github.com/nikic/test-repo/labels is incomplete though): Each
report has either a bug or feature label. Additionally it starts out with
the T-needs-triage label. Once a project member triages the report, the
label is removed and a category label is added instead, e.g. C-OpenSSL for
issues relating to the OpenSSL extension.

I also have a few more triage labels (T-needs-feedback, T-verified,
T-invalid, T-wontfix, T-duplicate), but I'm not sure we actually need any
but the first one or the first two -- I personally don't see a lot of value
in having a label for why exactly an issue has been closed, the fact that
it is closed is usually sufficient.

As for the migration itself, I think we should approach this the same way
as docs and open issues on php/php-src without actively migrating old
reports from bugs.php.net. We should retain bugs.php.net in read-only form
indefinitely, and also allow comments on old issues for the time being.

Regards,
Nikita

Jakub Zelenka

4 years ago

On Thu, Oct 21, 2021 at 4:07 PM Nikita Popov <nikita.ppv@gmail.com> wrote:

>
> I'm proposing the following label structure (the list at
> https://github.com/nikic/test-repo/labels is incomplete though): Each
> report has either a bug or feature label. Additionally it starts out with
> the T-needs-triage label. Once a project member triages the report, the
> label is removed and a category label is added instead, e.g. C-OpenSSL for
> issues relating to the OpenSSL extension.
>
> I also have a few more triage labels (T-needs-feedback, T-verified,
> T-invalid, T-wontfix, T-duplicate), but I'm not sure we actually need any
> but the first one or the first two -- I personally don't see a lot of value
> in having a label for why exactly an issue has been closed, the fact that
> it is closed is usually sufficient.
>
>

Have you considered custom fields that are now in beta with some other
features in https://github.com/features/issues ? That seems a bit nicer to
me...

Regards

Jakub

Nikita Popov

4 years ago

On Thu, Oct 21, 2021 at 10:42 PM Jakub Zelenka <bukka@php.net> wrote:

> On Thu, Oct 21, 2021 at 4:07 PM Nikita Popov <nikita.ppv@gmail.com> wrote:
>
>>
>> I'm proposing the following label structure (the list at
>> https://github.com/nikic/test-repo/labels is incomplete though): Each
>> report has either a bug or feature label. Additionally it starts out with
>> the T-needs-triage label. Once a project member triages the report, the
>> label is removed and a category label is added instead, e.g. C-OpenSSL for
>> issues relating to the OpenSSL extension.
>>
>> I also have a few more triage labels (T-needs-feedback, T-verified,
>> T-invalid, T-wontfix, T-duplicate), but I'm not sure we actually need any
>> but the first one or the first two -- I personally don't see a lot of
>> value
>> in having a label for why exactly an issue has been closed, the fact that
>> it is closed is usually sufficient.
>>
>>
> Have you considered custom fields that are now in beta with some other
> features in https://github.com/features/issues ? That seems a bit nicer
> to me...
>

Yes, I tested this as well (the PHP organization is signed up for the
beta). Unfortunately, I found this functionality rather awkward and don't
think it would work well for us. The key problem is that the new
functionality is not an improvement for issues -- it's an improvement for
"projects". You can add an issue to a project (manually) and then you can
add extra metadata to the issue in that project. It's not possible to add
custom fields to issues themselves.

Regards,
Nikita

Jakub Zelenka

4 years ago

On Thu, 21 Oct 2021, 22:46 Nikita Popov, <nikita.ppv@gmail.com> wrote:

> On Thu, Oct 21, 2021 at 10:42 PM Jakub Zelenka <bukka@php.net> wrote:
>
>> On Thu, Oct 21, 2021 at 4:07 PM Nikita Popov <nikita.ppv@gmail.com>
>> wrote:
>>
>>>
>>> I'm proposing the following label structure (the list at
>>> https://github.com/nikic/test-repo/labels is incomplete though): Each
>>> report has either a bug or feature label. Additionally it starts out with
>>> the T-needs-triage label. Once a project member triages the report, the
>>> label is removed and a category label is added instead, e.g. C-OpenSSL
>>> for
>>> issues relating to the OpenSSL extension.
>>>
>>> I also have a few more triage labels (T-needs-feedback, T-verified,
>>> T-invalid, T-wontfix, T-duplicate), but I'm not sure we actually need any
>>> but the first one or the first two -- I personally don't see a lot of
>>> value
>>> in having a label for why exactly an issue has been closed, the fact that
>>> it is closed is usually sufficient.
>>>
>>>
>> Have you considered custom fields that are now in beta with some other
>> features in https://github.com/features/issues ? That seems a bit nicer
>> to me...
>>
>
> Yes, I tested this as well (the PHP organization is signed up for the
> beta). Unfortunately, I found this functionality rather awkward and don't
> think it would work well for us. The key problem is that the new
> functionality is not an improvement for issues -- it's an improvement for
> "projects". You can add an issue to a project (manually) and then you can
> add extra metadata to the issue in that project. It's not possible to add
> custom fields to issues themselves.
>
>

Ah ok. That's a bit useless then. :) I agree that it wouldn't probably work
well for us though.

+1 on your proposal. I think that makes sense and could work well.

Regards

Jakub

Pierre Joye

4 years ago

Hi Joe,

On Sun, May 9, 2021, 1:49 PM Joe Watkins <krakjoe@php.net> wrote:

> Morning internals,
>
>
> Having moved our workflow to github, now seems to be the time to seriously
> consider retiring bugsnet for general use, and using the tools that are
> waiting for us - Github Issues.
>

yes! yes! yes!

and we could you projects/roadmap too together with gh APIs and the RFC.