Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114300
MIME-Version: 1.0
Date: Sun, 9 May 2021 08:48:54 +0200
Message-ID: <CAOwTYAtOti3+Tv9Cu5fK6bQ3tjAibRHUWOctnQFfGJyaoQYExw@mail.gmail.com>
To: PHP internals <internals@lists.php.net>, 
	PHP Release Managers <release-managers@php.net>
Content-Type: multipart/alternative; boundary="0000000000009f614f05c1e00edd"
Subject: Bugsnet
From: krakjoe@php.net (Joe Watkins)

--0000000000009f614f05c1e00edd
Content-Type: text/plain; charset="UTF-8"

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

--0000000000009f614f05c1e00edd--