Re: [PHP-DEV] [RFC] Migrating to GitHub issues
> if hosting it ourself is a priority, i suggest looking into GitLab’s > Community Edition, which is entirely open source, > and the GNOME project moved from Bugzilla to GitLab CE in 2018, > here's how that worked out, 2 years later: > https://about.gitlab.com/blog/2020/09/08/gnome-follow-up/ > (and the TL;DR is that it worked out great for the GNOME project) In my opinion, _not hosting it ourselves_ is a priority. Part of what bugs.php.net has shown is there is a lack of people who want and are willing to do the systems and maintenance tasks to run our own infrastructure. In this sense, I quite like GitHub, as it is one less thing that we have to maintain. Sure, we will have some custom tags, but this is quite minor compared to maintaining a system. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Migrating to GitHub issues
On Mon, 15 Nov 2021 at 09:47, Derick Rethans wrote: Derick wrote: > I think it is a mistake to decide on a whim to move over to GitHub > issues without having evaluated anything else. Maybe avoid being insulting about other people's decision making process? I'm pretty sure that Nikita doesn't make that many decisions on a whim, and that he has spent quite a bit of time over the past couple of weeks/months figuring out how it would work, and getting a test repo setup with the new issue templates. And I also believe he has spent signification time evaluating alternatives, but they all come up across the same problem listed in the RFC: "The requirement for an alternative would be that a) it is hosted (i.e. the PHP project does not need to maintain infrastructure for it), b) has good GitHub integration and c) is “sufficiently better” than GitHub issues to make it worth using a separate product." I don't think the vendor lock-in concern is that great. If Microsoft actually starts acting evil again, to the extent that we need to stop using Github for either code or issues, then we would be able to move again. The lock-in on github doesn't appear to be worse than bugs.php.net. In fact, it's far more likely that anything we would move to is going to have an "import from github" button, than anything having an "import from bugs.php.net" button. > This jump to GitHub Issues feels rushed, The topic has been discussed for at least 6 months: https://news-web.php.net/php.internals/114330 That seems like quite a bit of time for people who would prefer to avoid github to evaluate the alternatives and write out a plan. cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Migrating to GitHub issues
On Mon, 15 Nov 2021 at 09:56, Hans Henrik Bergan wrote: > > if hosting it ourself is a priority, No, quite the opposite. The PHP project is pretty terrible at running infrastructure, as infrastructure needs to have people available to work on it immediately when there are issues, which is not a good match a volunteer project. There is also the problem that a lot of maintenance needed for sites (or things like PEAR/PECL) are very boring, and so they are allowed to rot for years. Even if we had the resources to host something ourselves, doing so would come at an opportunity cost of not doing something that provides better value for the time. cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Migrating to GitHub issues
Chiming in, since it seems like people are suggesting Gitlab and further "exotic" tools. On Mon, Nov 15, 2021 at 6:06 PM Rowan Tommins wrote: > On 15/11/2021 14:49, Deleu wrote: > > I had already decided to spend time and effort learning about the > > project and then having to learn about their ticketing system and git > > repository is just unnecessary extra work. > > > In any project above a handful of developers, learning the conventions > and expectations of the community is always going to be far more > complicated than learning how to use the actual tools in question. We > should definitely choose a tool that is *easy to use*, and easy to > authenticate on (but not so easy it fills up with spam, like the current > one), but saying that developers will struggle to use anything other > than the One True Website is frankly insulting to the intelligence of > the average developer. > > The point of using Github (over other tools) is: * the community is already there * the repository is already frikken there * it's about pumping stuff into the issue tracker, nothing new is added * integrated CVE reports that already fit within the ecosystem * 2fa auth requirement for organization members (gitlab has this too, AFAIK, but it's a checkbox to add somewhere) * including pre-existing users in discussions (yes, leading to pings), even those that didn't declare a public mail - no registration and no GDPR to manage on PHP-SRC's end * rich editing of issues, with code fragments from the repo, rather than copy-pasta'd stuff all over the place * cross-linking of PHP sources with other project sources, including backlink references that make bugs and workarounds easier to follow by community members This stuff is not to be under-estimated: going self-hosted means having yet another insular environment, where the PHP-SRC folks are trapped in a bit of a void, and the actual discussions will keep happening on PHP-SRC diffs anyway. Instead of fearing the "One True Website", adopt and plan for disaster, should it become an Evil Corp seeding ground: what is there to be lost, and how hard would it be to recover? Greets, Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/
Re: [PHP-DEV] [RFC] Migrating to GitHub issues
On 15/11/2021 14:49, Deleu wrote: I had already decided to spend time and effort learning about the project and then having to learn about their ticketing system and git repository is just unnecessary extra work. In any project above a handful of developers, learning the conventions and expectations of the community is always going to be far more complicated than learning how to use the actual tools in question. We should definitely choose a tool that is *easy to use*, and easy to authenticate on (but not so easy it fills up with spam, like the current one), but saying that developers will struggle to use anything other than the One True Website is frankly insulting to the intelligence of the average developer. Regards, -- Rowan Tommins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Migrating to GitHub issues
Le lundi 15 novembre 2021, 15:49:04 CET Deleu a écrit : > Gitlab is not where the wide PHP Community is located. Composer, > widely-used and adopted packages, frameworks, PSRs, PHP itself and PHP Docs > are all hosted on GitHub. Choosing something else increases the barrier for > newcomers to become contributors. I speak from experience that when I tried > to contribute to Alpine Linux, one of the major turn off was GitLab > hosting. I had already decided to spend time and effort learning about the > project and then having to learn about their ticketing system and git > repository is just unnecessary extra work. This is exactly the problem with moving to Github, we are forcing everyone to come with us, as others are inciting us to go there by being there (composer, …). Then people only know how to use Github and we are stuck there forever. If we survived all these years with bugs.php.net, we should be alright with gitlab for sure. I think the PHP project could lead the way out of github instead of following the others in. Côme -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Migrating to GitHub issues
On Mon, Nov 15, 2021 at 8:49 AM Deleu wrote: > > > > > > I would like to suggest gitlab.com, which does provide hosting for free > > for opensource projects: https://about.gitlab.com/solutions/open-source/ > > Anyone with a github account can use it to log in. > > It should be easy to migrate to any other gitlab instance if needed. > There > > are even plans to one day have federation over gitlab instances. Not > > anytime soon, but likely sooner than github which is only hosted by > > Microsoft. > > > > Côme > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: https://www.php.net/unsub.php > > > > > Gitlab is not where the wide PHP Community is located. Composer, > widely-used and adopted packages, frameworks, PSRs, PHP itself and PHP Docs > are all hosted on GitHub. Choosing something else increases the barrier for > newcomers to become contributors. I speak from experience that when I tried > to contribute to Alpine Linux, one of the major turn off was GitLab > hosting. I had already decided to spend time and effort learning about the > project and then having to learn about their ticketing system and git > repository is just unnecessary extra work. > > PHP should not distance itself from its user base. > > Drupal Is currently in the process of migrating to a self hosted Gitlab instance. For some of the reasons highlighted by Derick but also because Github's issues and collaboration can be pretty terrible. There's hints of issue improvements on the horizon but we'll see. Gitlab however has been great in collaborating with us in addressing issues and collaborating on supporting our credit system. My impression is that Gnome switched because of the level of support and interest in Open Source communities so I wouldn't write them off without taking a look.
Re: [PHP-DEV] [RFC] Migrating to GitHub issues
> > > I would like to suggest gitlab.com, which does provide hosting for free > for opensource projects: https://about.gitlab.com/solutions/open-source/ > Anyone with a github account can use it to log in. > It should be easy to migrate to any other gitlab instance if needed. There > are even plans to one day have federation over gitlab instances. Not > anytime soon, but likely sooner than github which is only hosted by > Microsoft. > > Côme > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > > Gitlab is not where the wide PHP Community is located. Composer, widely-used and adopted packages, frameworks, PSRs, PHP itself and PHP Docs are all hosted on GitHub. Choosing something else increases the barrier for newcomers to become contributors. I speak from experience that when I tried to contribute to Alpine Linux, one of the major turn off was GitLab hosting. I had already decided to spend time and effort learning about the project and then having to learn about their ticketing system and git repository is just unnecessary extra work. PHP should not distance itself from its user base. -- Marco Aurélio Deleu
Re: [PHP-DEV] [RFC] Migrating to GitHub issues
I strongly agree with Derick on this matter. Le lundi 15 novembre 2021, 12:06:54 CET Nikita Popov a écrit : > For better or worse, GitHub is where nearly all open-source projects are > hosted, which means that pretty much anyone involved in open-source has an > account there and is familiar with the workflows. I do think that this is for worse, and that this situation exists because of decision like the one PHP is about to make. Saying we should use github because other projects use it is part of the problem. If PHP makes the switch we are encouraging other projects to do the same as well. We would be actively participating in this centralisation. > It is also where PHP > hosts it's repos and where we accept pull requests. Which I also think is a problem. A smaller one because of how git is distributed, but still annoying. The decision to move to github for the repositories was done in a hurry because of a security issue. It was the right decision to answer to the urgency of the situation back then I think, but it should not be used as a reason to go deeper down the rabbit hole. > An alternative issue > tracker has to compete not just on technical grounds, but also on > integration, familiarity and network-effect. For an open-source project, > these aspects are quite important when it comes to interaction with casual > contributors. > > Working at JetBrains, proposing YouTrack instead of GH issues has certainly > crossed my mind -- there is no doubt that at a technical level, it's a much > better bug tracker than GH issues. But that's simply not the right question > to ask. The right question is whether, given our rather simple > requirements, is it sufficiently better to overshadow the other benefits of > GitHub issues for an open-source project? I don't think so. We just need GH > issues to be "good enough" for our purposes, and I think that at this point > it is. > > I'll also mention that the discussion about this migration has been going > on for six months, and in that time all I've ever seen are vague mentions > of alternatives, but nobody has provided any in-depth analysis that goes > beyond a simple name drop. I went through the trouble of providing a > detailed evaluation of how the GitHub issues migration will look like, > while the alternatives are still at the state of "Phabricator is a thing" > (ooops, it actually isn't -- it managed to be discontinued while the > discussion was going on!) I would like to suggest gitlab.com, which does provide hosting for free for opensource projects: https://about.gitlab.com/solutions/open-source/ Anyone with a github account can use it to log in. It should be easy to migrate to any other gitlab instance if needed. There are even plans to one day have federation over gitlab instances. Not anytime soon, but likely sooner than github which is only hosted by Microsoft. Côme -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Migrating to GitHub issues
On Mon, Nov 15, 2021 at 10:47 AM Derick Rethans wrote: > Dear Internals, > > I think it is a mistake to decide on a whim to move over to GitHub > issues without having evaluated anything else. > > GitHub is a proprietary platform, where unlike with the code > repositories, the interactions and issues are not easy to migrate out of > again. It is also now owned by MSFT, and although they are making > friendly noises towards Open Source, I remain largely skeptical (with as > a hint, the stuff they're pulling with AI code completion). > > I understand and share that "bugsnet" has many issues, and I don't > necessarily object moving to something else. > > However, in the last 25+ years we've always hosted this ourselves, and > this prevented any sort of vendor lock in. I think it is important to > own our own data here, or at least have full access to any interactions. > > This jump to GitHub Issues feels rushed, and I worry that we end up > making the wrong decision, especially because from the RFC it seems we > need to build some functionality (tags scheme, for example) on top of > it. And this will need to be maintained separately, and I worry that too > few people are going to be interested in gardening the issues on GH. > > I believe we would be much better served having a look what is > available, and see what else is suitable. I'm therefore intending to > vote no on this. Hey Derick, The RFC includes a bit of discussion of alternatives in abstract ( https://wiki.php.net/rfc/github_issues#alternatives) and the key point (which has also been brought up by other people in the meantime) is that the choice of GitHub issues is very much not a whim: For better or worse, GitHub is where nearly all open-source projects are hosted, which means that pretty much anyone involved in open-source has an account there and is familiar with the workflows. It is also where PHP hosts it's repos and where we accept pull requests. An alternative issue tracker has to compete not just on technical grounds, but also on integration, familiarity and network-effect. For an open-source project, these aspects are quite important when it comes to interaction with casual contributors. Working at JetBrains, proposing YouTrack instead of GH issues has certainly crossed my mind -- there is no doubt that at a technical level, it's a much better bug tracker than GH issues. But that's simply not the right question to ask. The right question is whether, given our rather simple requirements, is it sufficiently better to overshadow the other benefits of GitHub issues for an open-source project? I don't think so. We just need GH issues to be "good enough" for our purposes, and I think that at this point it is. I'll also mention that the discussion about this migration has been going on for six months, and in that time all I've ever seen are vague mentions of alternatives, but nobody has provided any in-depth analysis that goes beyond a simple name drop. I went through the trouble of providing a detailed evaluation of how the GitHub issues migration will look like, while the alternatives are still at the state of "Phabricator is a thing" (ooops, it actually isn't -- it managed to be discontinued while the discussion was going on!) Finally, for me an important part of the migration (whether to GH Issues or something else) is specifically that we don't host it ourselves, because we have historically always been really bad at that. Of course, letting someone else host it is incompatible with the desire to fully "own" our data. I do appreciate the general sentiment here though. Regards, Nikita
Re: [PHP-DEV] [RFC] Migrating to GitHub issues
On 15.11.21 10:47, Derick Rethans wrote: GitHub is a proprietary platform, where unlike with the code repositories, the interactions and issues are not easy to migrate out of again. It is also now owned by MSFT, and although they are making friendly noises towards Open Source, I remain largely skeptical (with as a hint, the stuff they're pulling with AI code completion). All open-source projects I know and use in relation to PHP development are on Github (like Composer and Symfony, to just name two big ones), which in my opinion makes Github an ideal platform for the PHP project itself, as the barrier of entry is lowered. This also has the advantage that if Github "becomes evil" (or just gets worse) for whatever reasons, the PHP project will just be one of many open-source projects which needs to move to a new place. This gives this solution a safety in numbers and will probably make it easier to move rather than harder. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Migrating to GitHub issues
On Mon, Nov 15, 2021 at 10:47 AM Derick Rethans wrote: > > and I worry that too > few people are going to be interested in gardening the issues on GH. > > cheers, > Derick > > > On Tue, 2 Nov 2021, Nikita Popov wrote: > > > Hi internals, > > > > The migration from bugs.php.net to GitHub issues has already been > discussed > > in https://externals.io/message/114300 and has already happened for > > documentation issues. > > > > I'd like to formally propose to use GitHub for PHP implementation issues > as > > well: https://wiki.php.net/rfc/github_issues > > > > Regards, > > Nikita > > > > -- > 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 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > > If we do move over to GitHub I know that A LOT of young software engineers already learn how to use it which reduces the entry barrier. In fact, if it's possible to help triage bugs without C knowledge, I'm willing to be a candidate to help out since I know the whole "ticketing system" already, so it's just a matter of learning about tagging the content. Overall, I think moving to where developers are is a good decision because it becomes more accessible for a lot of people that may be willing to help. Self hosting means that 1) the choice of system will be something that the pool of people experienced in it will be less than GH Issues 2) someone will have to maintain the hosting infrastructure for it 3) it will be less accessible. I'm all for using GH Issues. -- Marco Aurélio Deleu
Re: [PHP-DEV] [RFC] Migrating to GitHub issues
if hosting it ourself is a priority, i suggest looking into GitLab’s Community Edition, which is entirely open source, and the GNOME project moved from Bugzilla to GitLab CE in 2018, here's how that worked out, 2 years later: https://about.gitlab.com/blog/2020/09/08/gnome-follow-up/ (and the TL;DR is that it worked out great for the GNOME project) On Mon, 15 Nov 2021 at 10:47, Derick Rethans wrote: > Dear Internals, > > I think it is a mistake to decide on a whim to move over to GitHub > issues without having evaluated anything else. > > GitHub is a proprietary platform, where unlike with the code > repositories, the interactions and issues are not easy to migrate out of > again. It is also now owned by MSFT, and although they are making > friendly noises towards Open Source, I remain largely skeptical (with as > a hint, the stuff they're pulling with AI code completion). > > I understand and share that "bugsnet" has many issues, and I don't > necessarily object moving to something else. > > However, in the last 25+ years we've always hosted this ourselves, and > this prevented any sort of vendor lock in. I think it is important to > own our own data here, or at least have full access to any interactions. > > This jump to GitHub Issues feels rushed, and I worry that we end up > making the wrong decision, especially because from the RFC it seems we > need to build some functionality (tags scheme, for example) on top of > it. And this will need to be maintained separately, and I worry that too > few people are going to be interested in gardening the issues on GH. > > I believe we would be much better served having a look what is > available, and see what else is suitable. I'm therefore intending to > vote no on this. > > cheers, > Derick > > > On Tue, 2 Nov 2021, Nikita Popov wrote: > > > Hi internals, > > > > The migration from bugs.php.net to GitHub issues has already been > discussed > > in https://externals.io/message/114300 and has already happened for > > documentation issues. > > > > I'd like to formally propose to use GitHub for PHP implementation issues > as > > well: https://wiki.php.net/rfc/github_issues > > > > Regards, > > Nikita > > > > -- > 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 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > >
Re: [PHP-DEV] [RFC] Migrating to GitHub issues
Hey Derick On Mon, Nov 15, 2021 at 10:47 AM Derick Rethans wrote: > Dear Internals, > > I think it is a mistake to decide on a whim to move over to GitHub > issues without having evaluated anything else. > > GitHub is a proprietary platform, where unlike with the code > repositories, the interactions and issues are not easy to migrate out of > again. It is also now owned by MSFT, and although they are making > friendly noises towards Open Source, I remain largely skeptical (with as > a hint, the stuff they're pulling with AI code completion). > > I understand and share that "bugsnet" has many issues, and I don't > necessarily object moving to something else. > > However, in the last 25+ years we've always hosted this ourselves, and > this prevented any sort of vendor lock in. I think it is important to > own our own data here, or at least have full access to any interactions. > > This jump to GitHub Issues feels rushed, and I worry that we end up > making the wrong decision, especially because from the RFC it seems we > need to build some functionality (tags scheme, for example) on top of > it. And this will need to be maintained separately, and I worry that too > few people are going to be interested in gardening the issues on GH. > > I believe we would be much better served having a look what is > available, and see what else is suitable. I'm therefore intending to > vote no on this. > > cheers, > Derick > Remember that all information on public repos is also available on http://www.gharchive.org/ If data retention is the problem, mirroring that could be an effective solution. Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/
Re: [PHP-DEV] [RFC] Migrating to GitHub issues
Dear Internals, I think it is a mistake to decide on a whim to move over to GitHub issues without having evaluated anything else. GitHub is a proprietary platform, where unlike with the code repositories, the interactions and issues are not easy to migrate out of again. It is also now owned by MSFT, and although they are making friendly noises towards Open Source, I remain largely skeptical (with as a hint, the stuff they're pulling with AI code completion). I understand and share that "bugsnet" has many issues, and I don't necessarily object moving to something else. However, in the last 25+ years we've always hosted this ourselves, and this prevented any sort of vendor lock in. I think it is important to own our own data here, or at least have full access to any interactions. This jump to GitHub Issues feels rushed, and I worry that we end up making the wrong decision, especially because from the RFC it seems we need to build some functionality (tags scheme, for example) on top of it. And this will need to be maintained separately, and I worry that too few people are going to be interested in gardening the issues on GH. I believe we would be much better served having a look what is available, and see what else is suitable. I'm therefore intending to vote no on this. cheers, Derick On Tue, 2 Nov 2021, Nikita Popov wrote: > Hi internals, > > The migration from bugs.php.net to GitHub issues has already been discussed > in https://externals.io/message/114300 and has already happened for > documentation issues. > > I'd like to formally propose to use GitHub for PHP implementation issues as > well: https://wiki.php.net/rfc/github_issues > > Regards, > Nikita > -- 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Migrating to GitHub issues
On Wed, Nov 10, 2021 at 7:23 PM Niklas Keller wrote: > Hey Nikita, > > I'd like to propose using HackerOne instead of bugs.php.net for security > issues: https://www.hackerone.com/company/open-source-community > > Best, > Niklas > Unfortunately I have no familiarity with HackerOne and as such don't know whether it would work for our purposes. I think an important requirement for us is that maintainers who are not otherwise involved in security response can be assigned to (and see) issues. I'm hazy on the details, but I believe that PHP used to be part of IBB on HackerOne and was kicked out due to lack of responsiveness (apparently nobody from the PHP side was actually involved there). Regards, Nikita
Re: [PHP-DEV] [RFC] Migrating to GitHub issues
On Wed, Nov 10, 2021 at 5:51 PM Nikita Popov wrote: > On Thu, Nov 4, 2021 at 5:58 PM Dan Ackroyd wrote: > >> On Tue, 2 Nov 2021 at 14:19, Nikita Popov wrote: >> > >> > I'd like to formally propose to use GitHub for PHP implementation >> issues as >> > well: https://wiki.php.net/rfc/github_issues >> >> In general, yes please. The only bit I'll chime in on is: >> >> > bugs.php.net will remain active for the following purposes: >> > Reporting of issues against PECL extensions. (We may want to discontinue >> > this as well. Many actively maintained extensions already use GitHub >> issues >> > rather than bugs.php.net.) >> >> >> Providing a bug reporting site was a useful thing to do 23 years ago, >> as it would have been either expensive or time consuming for each >> project to set up their own. It doesn't seem as sensible now as: >> >> * Having bugs.php.net remain open for some bits of PHP, but not >> others, would be confusing for users. >> >> * Most extensions are hosted on a platform that already provides issue >> tracking - though it seems quite a few extensions (including Imagick) >> have not realised that there is a bug tracking setting that can/should >> be updated on pecl. >> >> * There's an ongoing issue of extensions becoming unmaintained over >> time. If people are opening bugs on the PHP issue tracker, it's >> natural for them to have an expectation that someone from the PHP >> project would work on that issue at some point. >> >> So unless someone has a strong argument for keeping the bugs.php.net >> open for PECL extensions, I think it shouldn't be. >> >> btw it would probably be useful to dump out a list of where to report >> bugs for different extensions and put that as a page on bugs.php.net >> though. If nothing else, Google thinks Imagick is an alias for >> ImageMagick far too often and sometimes pecl.php.net is unresponsive. > > > Yes, we should definitely migrate PECL extensions away from bugs.php.net > as well. I didn't cover this in the RFC because it doesn't really relate to > the setup described there and this part of the migration can happen in > parallel. > > To migrate PECL extensions hosted by the PHP organization away from > bugs.php.net, we need to: > 1. Enable GH issues on the repo. > 2. Disable the package on bugs.php.net. > 3. Update the bug tracker URL on pecl.php.net. > 4. (Maybe) manually migrate outstanding open bugs. > > For extensions not hosted by the PHP organization we may have to contact > maintainers to determine which issue tracker to use. > As an update here: I've gone through all the PECL packages on bugs.php.net and found that nearly all of them are either unmaintained or already have a different bugtracker (almost always GitHub issues). Those packages are now disabled and cmb has updated the bug tracker URLs on pecl.php.net. Next step will be to open GH issues for repos that the PHP organization owns, and then we'll have to see what to do with the handful of remaining extensions. I've updated the RFC to say that bugs.php.net to say that it will not remain open for PECL extensions either. Regards, Nikita
Re: [PHP-DEV] [RFC] Migrating to GitHub issues
Hey Nikita, I'd like to propose using HackerOne instead of bugs.php.net for security issues: https://www.hackerone.com/company/open-source-community Best, Niklas Am Di., 2. Nov. 2021 um 15:19 Uhr schrieb Nikita Popov : > Hi internals, > > The migration from bugs.php.net to GitHub issues has already been > discussed > in https://externals.io/message/114300 and has already happened for > documentation issues. > > I'd like to formally propose to use GitHub for PHP implementation issues as > well: https://wiki.php.net/rfc/github_issues > > Regards, > Nikita >
Re: [PHP-DEV] [RFC] Migrating to GitHub issues
On Thu, Nov 4, 2021 at 5:58 PM Dan Ackroyd wrote: > On Tue, 2 Nov 2021 at 14:19, Nikita Popov wrote: > > > > I'd like to formally propose to use GitHub for PHP implementation issues > as > > well: https://wiki.php.net/rfc/github_issues > > In general, yes please. The only bit I'll chime in on is: > > > bugs.php.net will remain active for the following purposes: > > Reporting of issues against PECL extensions. (We may want to discontinue > > this as well. Many actively maintained extensions already use GitHub > issues > > rather than bugs.php.net.) > > > Providing a bug reporting site was a useful thing to do 23 years ago, > as it would have been either expensive or time consuming for each > project to set up their own. It doesn't seem as sensible now as: > > * Having bugs.php.net remain open for some bits of PHP, but not > others, would be confusing for users. > > * Most extensions are hosted on a platform that already provides issue > tracking - though it seems quite a few extensions (including Imagick) > have not realised that there is a bug tracking setting that can/should > be updated on pecl. > > * There's an ongoing issue of extensions becoming unmaintained over > time. If people are opening bugs on the PHP issue tracker, it's > natural for them to have an expectation that someone from the PHP > project would work on that issue at some point. > > So unless someone has a strong argument for keeping the bugs.php.net > open for PECL extensions, I think it shouldn't be. > > btw it would probably be useful to dump out a list of where to report > bugs for different extensions and put that as a page on bugs.php.net > though. If nothing else, Google thinks Imagick is an alias for > ImageMagick far too often and sometimes pecl.php.net is unresponsive. Yes, we should definitely migrate PECL extensions away from bugs.php.net as well. I didn't cover this in the RFC because it doesn't really relate to the setup described there and this part of the migration can happen in parallel. To migrate PECL extensions hosted by the PHP organization away from bugs.php.net, we need to: 1. Enable GH issues on the repo. 2. Disable the package on bugs.php.net. 3. Update the bug tracker URL on pecl.php.net. 4. (Maybe) manually migrate outstanding open bugs. For extensions not hosted by the PHP organization we may have to contact maintainers to determine which issue tracker to use. Regards, Nikita
Re: [PHP-DEV] [RFC] Migrating to GitHub issues
On Tue, 2 Nov 2021 at 14:19, Nikita Popov wrote: > > I'd like to formally propose to use GitHub for PHP implementation issues as > well: https://wiki.php.net/rfc/github_issues In general, yes please. The only bit I'll chime in on is: > bugs.php.net will remain active for the following purposes: > Reporting of issues against PECL extensions. (We may want to discontinue > this as well. Many actively maintained extensions already use GitHub issues > rather than bugs.php.net.) Providing a bug reporting site was a useful thing to do 23 years ago, as it would have been either expensive or time consuming for each project to set up their own. It doesn't seem as sensible now as: * Having bugs.php.net remain open for some bits of PHP, but not others, would be confusing for users. * Most extensions are hosted on a platform that already provides issue tracking - though it seems quite a few extensions (including Imagick) have not realised that there is a bug tracking setting that can/should be updated on pecl. * There's an ongoing issue of extensions becoming unmaintained over time. If people are opening bugs on the PHP issue tracker, it's natural for them to have an expectation that someone from the PHP project would work on that issue at some point. So unless someone has a strong argument for keeping the bugs.php.net open for PECL extensions, I think it shouldn't be. btw it would probably be useful to dump out a list of where to report bugs for different extensions and put that as a page on bugs.php.net though. If nothing else, Google thinks Imagick is an alias for ImageMagick far too often and sometimes pecl.php.net is unresponsive. cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Migrating to GitHub issues
On Tue, Nov 2, 2021 at 9:19 AM Nikita Popov wrote: > The migration from bugs.php.net to GitHub issues has already been > discussed > in https://externals.io/message/114300 and has already happened for > documentation issues. > > I'd like to formally propose to use GitHub for PHP implementation issues as > well: https://wiki.php.net/rfc/github_issues > > IMO the more custom infra we get rid of the better. I'll volunteer to update the news2html script we use for creating Changelog files. -Sara
[PHP-DEV] [RFC] Migrating to GitHub issues
Hi internals, The migration from bugs.php.net to GitHub issues has already been discussed in https://externals.io/message/114300 and has already happened for documentation issues. I'd like to formally propose to use GitHub for PHP implementation issues as well: https://wiki.php.net/rfc/github_issues Regards, Nikita
