# Bugsnet - Thread: https://externals.io/message/114300 - Original archive: https://news-web.php.net/php.internals/114300 - Started by Joe Watkins on 2021-05-09T06:48:54+00:00 - Messages: 40 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/114300.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #114300 — Joe Watkins — 2021-05-09T06:48:54+00:00 URL: https://externals.io/message/114300#114300 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 --- ## #114301 — Sebastian Bergmann — 2021-05-09T06:55:12+00:00 URL: https://externals.io/message/114300#114301 · In reply to: #114300 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. --- ## #114302 — Kalle Sommer Nielsen — 2021-05-09T07:17:55+00:00 URL: https://externals.io/message/114300#114302 · In reply to: #114300 Den søn. 9. maj 2021 kl. 09.49 skrev Joe Watkins : > > 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 --- ## #114303 — Stanislav Malyshev — 2021-05-09T07:33:08+00:00 URL: https://externals.io/message/114300#114303 · In reply to: #114300 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 --- ## #114304 — Sebastian Bergmann — 2021-05-09T07:36:52+00:00 URL: https://externals.io/message/114300#114304 · In reply to: #114303 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 --- ## #114305 — Joe Watkins — 2021-05-09T07:47:50+00:00 URL: https://externals.io/message/114300#114305 · In reply to: #114303 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 > Hi! > > > […] > > 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 > > > […] > > 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. > > > […] > > 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 --- ## #114306 — Stanislav Malyshev — 2021-05-09T08:05:44+00:00 URL: https://externals.io/message/114300#114306 · In reply to: #114305 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 --- ## #114307 — Andreas Heigl — 2021-05-09T08:08:33+00:00 URL: https://externals.io/message/114300#114307 · In reply to: #114303 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 > > > […] > > 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. > > > […] > > 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 | +---------------------------------------------------------------------+ --- ## #114308 — Joe Watkins — 2021-05-09T08:16:42+00:00 URL: https://externals.io/message/114300#114308 · In reply to: #114307 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 > Hey folks: > > Am 09.05.21 um 09:33 schrieb Stanislav Malyshev: > > […] > [...] > > […] > search > > […] > closed/open) > > […] > > 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 | > +---------------------------------------------------------------------+ > > -- > > To unsubscribe, visit: https://www.php.net/unsub.php --- ## #114309 — andre@webkr.de — 2021-05-09T08:24:58+00:00 URL: https://externals.io/message/114300#114309 · In reply to: #114300 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. --- ## #114310 — Rowan Tommins — 2021-05-09T08:58:17+00:00 URL: https://externals.io/message/114300#114310 · In reply to: #114303 >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] --- ## #114311 — Mark Randall — 2021-05-09T13:31:09+00:00 URL: https://externals.io/message/114300#114311 · In reply to: #114306 > 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. --- ## #114312 — Larry Garfield — 2021-05-09T14:25:56+00:00 URL: https://externals.io/message/114300#114312 · In reply to: #114300 > 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 --- ## #114314 — Jakub Zelenka — 2021-05-09T15:26:31+00:00 URL: https://externals.io/message/114300#114314 · In reply to: #114300 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 --- ## #114315 — Max Semenik — 2021-05-09T15:30:03+00:00 URL: https://externals.io/message/114300#114315 · In reply to: #114310 On Sun, May 9, 2021 at 11:58 AM Rowan Tommins 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 --- ## #114317 — Wim Godden — 2021-05-09T15:51:57+00:00 URL: https://externals.io/message/114300#114317 · In reply to: #114300 > 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 --- ## #114318 — Max Semenik — 2021-05-09T17:19:51+00:00 URL: https://externals.io/message/114300#114318 · In reply to: #114310 On Sun, May 9, 2021 at 11:58 AM Rowan Tommins 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 --- ## #114319 — Levi Morrison — 2021-05-09T20:52:11+00:00 URL: https://externals.io/message/114300#114319 · In reply to: #114312 > > > > […] > > 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 > > -- > > 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. --- ## #114320 — Rowan Tommins — 2021-05-09T21:49:52+00:00 URL: https://externals.io/message/114300#114320 · In reply to: #114315 > 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] --- ## #114321 — Stanislav Malyshev — 2021-05-09T23:55:06+00:00 URL: https://externals.io/message/114300#114321 · In reply to: #114320 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 --- ## #114322 — Mike Schinkel — 2021-05-10T01:37:07+00:00 URL: https://externals.io/message/114300#114322 · In reply to: #114310 > > > > > […] > > > 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/skope-github-issue-tracker https://github.com/marketplace/orwell-app 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 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/googleapis/google-api-php-client https://github.com/mpscholten/github-api 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 --- ## #114323 — Benjamin Eberlei — 2021-05-10T07:56:55+00:00 URL: https://externals.io/message/114300#114323 · In reply to: #114300 > 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. > 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 --- ## #114330 — Derick Rethans — 2021-05-10T09:10:58+00:00 URL: https://externals.io/message/114300#114330 · In reply to: #114300 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 --- ## #114336 — Alexander Kurilo via internals — 2021-05-10T12:44:55+00:00 URL: https://externals.io/message/114300#114336 · In reply to: #114300 > 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 --- ## #114338 — Dan Ackroyd — 2021-05-10T13:28:37+00:00 URL: https://externals.io/message/114300#114338 · In reply to: #114320 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 --- Next page: https://externals.io/message/114300.md?page=2