GitHub has become increasingly unreliable. I suggest the Boost project explore alternatives to be ready in case the need to move to a new hosted provider arises. We (the C++ Alliance) are investigating Codeberg. Regards, Vinnie Follow me on GitHub: https://github.com/vinniefalco
On Sun, May 10, 2026 at 7:28 PM Vinnie Falco <vinnie.falco@gmail.com> wrote:
GitHub has become increasingly unreliable.
Some conversation starters: https://leaddev.com/software-quality/whats-gone-wrong-at-github https://dbushell.com/2026/04/29/github-is-sinking/ <https://github.com/vinniefalco>
On May 10, 2026, at 5:02 PM, Peter Taraba via Boost <boost@lists.boost.org> wrote:
I support moving away from Microsoft. They can't be trusted anymore.
Which is kind of sad. I used to think that they could not be trusted. Then they showed that they could run GitHub well - I was surprised and pleased. Then they showed that they could no longer run it well. — Marshall
On Sun, May 10, 2026 at 9:07 PM Marshall Clow via Boost < boost@lists.boost.org> wrote:
On May 10, 2026, at 5:02 PM, Peter Taraba via Boost <boost@lists.boost.org> wrote: Then they showed that they could no longer run it well
Yep. So, there is no urgency, and we should start thinking about what a migration plan might look like. How do we extract the open issues and transfer them? What do we do with the CI system? Release packages? Open pull requests? If for example we want to transfer the open issues then we should start collecting them now, because of rate limits (it could take weeks or months to collect all the data which is not stored in the repo). We also might think about the libraries which are not actively maintained (if any?) we could reach out to authors and make sure everyone is aware and involved in planning a migration. If we prepare now, we can be ready ahead of time, instead of having the issue forced on us when things become untenable at GitHub. Thanks
On Mon, May 11, 2026 at 9:53 AM Vinnie Falco via Boost < boost@lists.boost.org> wrote:
On Sun, May 10, 2026 at 9:07 PM Marshall Clow via Boost < boost@lists.boost.org> wrote:
On May 10, 2026, at 5:02 PM, Peter Taraba via Boost < boost@lists.boost.org> wrote: Then they showed that they could no longer run it well
I've used Gitea a few years ago and it looks like Codeberg's Forgejo is a clone. Back then Drone CI worked great with Gitea. It seems that drone has been forked into Woodpeckers CI as well, which Forgejo is using by default.
Thus, the existing drone scripts should largely work. So either Gitea + Drone or Forgejo + Woodpeckers sound great to me.
Yep. So, there is no urgency, and we should start thinking about what a migration plan might look like. How do we extract the open issues and transfer them? What do we do with the CI system? Release packages? Open pull requests?
I think the first attempt should be to spin up a mirror of either Forgejo and/or Gitea and see how it works. And then we set a date, at which we disable issues and PRs on Github and use github as a pure (and automated) mirror.
If for example we want to transfer the open issues then we should start collecting them now, because of rate limits (it could take weeks or months to collect all the data which is not stored in the repo).
Both have an "import from github" function, that allows you to import a full project. This is probably a good default, unless a maintainer wants to do it another way (e.g. only transfer certains issues).
We also might think about the libraries which are not actively maintained (if any?) we could reach out to authors and make sure everyone is aware and involved in planning a migration.
If we prepare now, we can be ready ahead of time, instead of having the issue forced on us when things become untenable at GitHub.
Thanks _______________________________________________ Boost mailing list -- boost@lists.boost.org To unsubscribe send an email to boost-leave@lists.boost.org https://lists.boost.org/mailman3/lists/boost.lists.boost.org/ Archived at: https://lists.boost.org/archives/list/boost@lists.boost.org/message/3SYG4QWS...
Am 11.05.26 um 04:18 schrieb Klemens Morgenstern via Boost:
I think the first attempt should be to spin up a mirror of either Forgejo and/or Gitea and see how it works. And then we set a date, at which we disable issues and PRs on Github and use github as a pure (and automated) mirror.
If for example we want to transfer the open issues then we should start collecting them now, because of rate limits (it could take weeks or months to collect all the data which is not stored in the repo).
Both have an "import from github" function, that allows you to import a full project. This is probably a good default, unless a maintainer wants to do it another way (e.g. only transfer certains issues).
TBH: Not really keen on that. I'm aware of the sunken costs fallacy but there IS a lot of effort in and around GitHub that we would/might loose. That includes experience of us and users on how to do things there and how to handle issues difficulties. E.g. Boost.CI and the "reusable" workflow introduced by Jim last year helps to have up to date configurations for lot's of Boost libraries, especially those where CI is/was rooting away as maintainers were either not that active anymore or simply didn't want to keep track of the changes required for very new or old configurations. Drone is only part way on that state where a new compiler can be tested and added to dozens of libraries in a single commit to a central repository. So far my work on GitHub wasn't affected to an extent I'd even notice much. Especially with Boost we are not that highly active that even a day outage would be catastrophic. I'd put it as "mildly annoying" instead. And the article shared by Vinnie [1] sounds like there is some hope:
GitHub. It is critical global infrastructure, and it is struggling under the weight of millions (if not billions) of AI agents spewing out code.
GitHub’s stated priorities are now availability first, capacity second, new features third. That’s the right order,
So IMO this is a temporary struggle with the changing landscape of software development and MS at least seems to be aware and dedicated to handle that. So I would wait for this to calm down again but keep stuff like this in mind. If anyone has the time to test alternatives on what is viable if it comes to that, it would certainly be good to know. Especially how well issues and references to PRs, commits and other issues are kept as that proved to be useful in multiple occasions to me. But I wouldn't want to do the switch, at least not now. - Alex [1] https://leaddev.com/software-quality/whats-gone-wrong-at-github
I agree with Alex here. Although I would be happy to ditch Microsoft for an European solution, my main problem is that the Boost.Graph users we just connected with and promised less friction would be affected in how they participate in and engage with Boost.Graph. My main problem with Codeberg is the lack of a feature similar to GH Discussions. Those are not always enabled on repos, but I see them as essential for large-scope projects with many hidden users, old history and a way to reach out. They act essentially as a projec-hosted forum that allows signaling and preserving community debates around APIs, usages, complaints etc. They are functionally different from issues: - Issues are for bug reports, code defects, and actionable items, the quality-to-noise ratio for a good issue is high. - Discussions are a support/forum space for the project: questions, feature ideas, announcements, polls, "how do I configure this on XYZ" type help. Not necessarily actionable, although if relevant these can be converted to issues. Without a dedicated discussion space, issues become the recipient space for items that are not always actionable. The BGL issue tracker is somewhat encumbered by items that would rather belong in Discussions. What particularly worries me is that we heavily and successfully depended on GH Discussions to announce and organize the BGL Workshop last Wednesday, as I believe they are an essential part of revitalizing BGL and its community. We were positively surprised by the amount of participation and the quality of the feedback that the single announcement page collected: https://github.com/boostorg/graph/discussions/466 Leaving GH would mean dropping this feature, which has been discussed for years at Codeberg ( https://codeberg.org/forgejo/forgejo/issues/410 ). It would deprive BGL maintainers from their most efficient way to reach users at a critical time. It would also send a terrible message to BGL users who invested in those discussions and strongly asked for less friction, not more. I am aware that 1) what holds for Boost.Graph may not be true for other projects 2) vinnie said there was no urgency So as long as Github shittification makes maintainers lives harder but keep users happy, I would be tempted to absorb the cost at least for now. Best wishes, Arnaud Becheler On Mon, May 11, 2026 at 9:29 AM Alexander Grund via Boost < boost@lists.boost.org> wrote:
Am 11.05.26 um 04:18 schrieb Klemens Morgenstern via Boost:
I think the first attempt should be to spin up a mirror of either Forgejo and/or Gitea and see how it works. And then we set a date, at which we disable issues and PRs on Github and use github as a pure (and automated) mirror.
If for example we want to transfer the open issues then we should start collecting them now, because of rate limits (it could take weeks or months to collect all the data which is not stored in the repo).
Both have an "import from github" function, that allows you to import a full project. This is probably a good default, unless a maintainer wants to do it another way (e.g. only transfer certains issues).
TBH: Not really keen on that. I'm aware of the sunken costs fallacy but there IS a lot of effort in and around GitHub that we would/might loose. That includes experience of us and users on how to do things there and how to handle issues difficulties. E.g. Boost.CI and the "reusable" workflow introduced by Jim last year helps to have up to date configurations for lot's of Boost libraries, especially those where CI is/was rooting away as maintainers were either not that active anymore or simply didn't want to keep track of the changes required for very new or old configurations. Drone is only part way on that state where a new compiler can be tested and added to dozens of libraries in a single commit to a central repository.
So far my work on GitHub wasn't affected to an extent I'd even notice much. Especially with Boost we are not that highly active that even a day outage would be catastrophic. I'd put it as "mildly annoying" instead.
And the article shared by Vinnie [1] sounds like there is some hope:
GitHub. It is critical global infrastructure, and it is struggling under the weight of millions (if not billions) of AI agents spewing out code.
GitHub’s stated priorities are now availability first, capacity second, new features third. That’s the right order,
So IMO this is a temporary struggle with the changing landscape of software development and MS at least seems to be aware and dedicated to handle that.
So I would wait for this to calm down again but keep stuff like this in mind. If anyone has the time to test alternatives on what is viable if it comes to that, it would certainly be good to know. Especially how well issues and references to PRs, commits and other issues are kept as that proved to be useful in multiple occasions to me. But I wouldn't want to do the switch, at least not now.
- Alex
[1] https://leaddev.com/software-quality/whats-gone-wrong-at-github
_______________________________________________ Boost mailing list -- boost@lists.boost.org To unsubscribe send an email to boost-leave@lists.boost.org https://lists.boost.org/mailman3/lists/boost.lists.boost.org/ Archived at: https://lists.boost.org/archives/list/boost@lists.boost.org/message/XLH3UJ65...
participants (6)
-
Alexander Grund -
Arnaud Becheler -
Klemens Morgenstern -
Marshall Clow -
Peter Taraba -
Vinnie Falco