Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114319
MIME-Version: 1.0
References: <CAOwTYAtOti3+Tv9Cu5fK6bQ3tjAibRHUWOctnQFfGJyaoQYExw@mail.gmail.com>
 <7afdf545-8b46-474e-85e5-0a0393fb09b2@www.fastmail.com>
In-Reply-To: <7afdf545-8b46-474e-85e5-0a0393fb09b2@www.fastmail.com>
Date: Sun, 9 May 2021 14:52:11 -0600
Message-ID: <CAFMT4Nr5k7Dn9b73wTHPBcp4JAh9fEN32NxwkYKDuADgJge3fw@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Bugsnet
From: levim@php.net (Levi Morrison)

On Sun, May 9, 2021 at 8:26 AM Larry Garfield <larry@garfieldtech.com> wrot=
e:
>
> 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 t=
o
> > 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 sour=
ce
> > 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 seriou=
sly
> > 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 bug=
s
> > and github doesn't have a solution to that. Leaving that to one side fo=
r
> > now ...
> >
> > I'm also aware that bugsnet carries with it 20 years worth of crusty ol=
d
> > feature requests and bugs, that are never realistically going to be dea=
lt
> > 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 bugsn=
et,
> > 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 late=
r
> > date. Leaving bugsnet in a (mostly) readonly mode.
> >
> > We then send a notification to all bugs that were opened against a spec=
ific
> > 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 gi=
thub.
> >
> > I think we might get quite a good response here - anyone suffering the
> > worst consequences of bugs - production servers can't be upgraded and s=
o 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 respo=
nse
> > to our switching over to github, we can try to determine at that time i=
f
> > 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 additi=
on,
> > I feel people are less likely to misbehave if they think their co-worke=
rs
> > or employers might be able to see what they are doing, which may have a=
n
> > 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 t=
he
> > perfect tool for the job, nothing else is either. We could spend time
> > (which we don't have) developing bugsnet, or installing some other solu=
tion
> > 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 t=
hat
> > I'm most interested in, they are the people who will be and have been m=
ost
> > effected by the shortcomings in bugsnet, whose opinions are most releva=
nt
> > in this space.
> >
> > I don't think a vote is appropriate, this decision should be made by th=
e
> > people whose "jobs" are directly effected - with input from the communi=
ty,
> > of course. Not least of all, it will take a month to close a vote, by w=
hich
> > 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 th=
ink
> > 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 revi=
ew
> > 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 th=
e release managers, very-high-level contributors (Nikita, Dmitry, etc.), an=
d whatever passes for sysadmins around here. :-)  As a fan of decoupling, h=
owever, I want to note that it sounds like there's a couple of separate iss=
ues 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 hav=
e 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, f=
or 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 ti=
me to declare bankruptcy.
> GitHub answer: Migrating to a new system is a good opportunity to purge o=
ld issues.
> Alternatives/limitations: Migrating GitLab, self-hosted GitLab, YouTrack,=
 Bugzilla, or any other tool would offer a similar `rf -rf` opportunity.  B=
ut no matter where we move, the same pile of old issues is going to reappea=
r 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 dec=
lare 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 go=
od PHP is at that...
> GitHub answer: Hosted, not our problem.
> Alternatives/limitations: This would be equally-well resolved by using an=
y 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 customizab=
ility will depend on the tool.
>
> Problem: Having the bug list and code hosting in different places is weir=
d and confusing.
> GitHub answer: So give them all to us!
> Alternatives/limitations: There are other code-and-issue tools (eg, GitLa=
b) 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 st=
raightforward.  GitHub only has an advantage here because of its popularity=
 and because that's where the code moved to after the server hack.  Also, t=
here's probably an argument to be made that keeping those tools separate ha=
s 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 j=
ust want to make sure the lay of the land is clear, and there's a clear pic=
ture 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 issue=
s 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.