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
