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 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...

On Thu, 2026-05-14 at 12:38 +0200, Seth via Boost wrote:

It seems you are referring to optional features.

GitLab can even be self-hosted from official packages, or you can compile the community edition from source yourself

# Clone GitLab repository sudo -u git -H git clone https://gitlab.com/gitlab-org/gitlab-foss.git -b <X-Y-stable> gitlab

Full docs https://docs.gitlab.com/install/self_compiled/

I may not be fully aware of additional licensing constraints so I welcome anyone who has a comparison matrix of licensing/hosting/support options. I know several people who self-host GitLab for free.

If you'll accept using Docker or a Docker-compatible runtime, then it becomes trivial to host, backup, and update GitLab. https://hub.docker.com/r/gitlab/gitlab-ce https://docs.gitlab.com/install/docker/installation/#install-gitlab-by-using... The setup to get a running instance is straightforward and can be done is under 5 minutes. Slightly more involved is setting up email, any firewalls, configuring the application, and "tuning" it for performance/resource usage. Out of the box, a busy instance might use 10-50GB of memory but this can be managed by configuring task/worker counts, etc. Some of the default settings are not ideal. It requires a full comb-through alongside the documentation on first setup, and then some effort to track "new" settings after each update. Depending on your bandwidth/storage needs, and whether any small amount of downtime is acceptible, will add some complexity to both the setup and backup/update/maintenance aspects. A complete backup might be trivial if massive files and other artifacts/images aren't stored in the instance. Without Docker or compatible tool, it's slightly less turnkey but still doable for a competent sysadmin. Less intuitive but important knowledge is most comprehensively documented. For example, it's critical to update to the latest minor release before updating to the next major release, and between each update it's critical to verify that all "background" tasks have completed. There are more such cases but it's quite manageable. Just follow the instructions exactly and don't make assumptions. While GitLab the company is causing a stir at the moment, and while GitLab the software has become "feature rich" it's still a decent platform for folks who are used to GitHub the platform. I've been self-hosting GitLab for myself and companies/projects for a long time. I don't like where the product is going but I'm still willing to recommend others at least give it a chance. Z

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

There almost seems to be an accepted implication this thread, which is "codeberg is better than github". Or "more reliable". Is it? The starting point of the discussion was github outages. Question to chatgpt: In terms of stability, reliability, and also breadth of features, which is preferable github or codeberg? Answer: If your priorities are primarily stability, operational reliability, ecosystem breadth, integrations, and enterprise-grade features, then GitHub is still substantially ahead of Codeberg. Question to claude: In terms of stability, reliability, and also breadth of features, which is preferable github or codeberg? Claude responded: Based on the research already done, this is fairly clear-cut: GitHub wins on both counts, and it's not close. "Reliability: a real concern. This is the weakest point. Over 2025, Codeberg Pages availability was measured at 98.358% — a "one-nine" uptime — with 489 periods of downtime, the longest approaching 17 hours. GitHub Pages took the top spot in uptime comparisons. That's meaningfully worse than GitHub for hosted content. The core Git hosting may differ, but it suggests infrastructure strain at scale." Yes there have been annoying outages. But how many boost developers have been so impacted, it has disrupted your work badly enough, that for this reason, you want to migrate? Mainly: the sheer number of scripts, programs (in the whole C++ ecosystem and in boost), CI, repositories, api queries, which are pointing at github.com or depend on features provided by github, and inconvenienced by a switch-over, indicates that the threshold to migrate should not merely be "approximately the same level of git hosting experience" to be worth the effort, but a significantly improved service. On Mon, May 11, 2026 at 10:10 AM Arnaud Becheler via Boost < boost@lists.boost.org> wrote:

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...

...

_______________________________________________ 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/4OKKCF5U...

On Mon, May 11, 2026 at 12:18 PM Andrey Semashev via Boost < boost@lists.boost.org> wrote:

The scary part is that some of the recent issues on GitHub were not the downtime but data corruption that could go unnoticed. Specifically, I'm referring to the recent issue with PR merges that removed commits from the target branches.

“You had one job.” This is literally the worst kind of failure. Perhaps the urgency is greater than I estimated. Thanks

On 11 May 2026 19:24, Vinnie Falco wrote:

On Mon, May 11, 2026 at 12:09 PM Andrey Semashev via Boost <boost@lists.boost.org <mailto:boost@lists.boost.org>> wrote:

For example, drone.cpp.al <http://drone.cpp.al> is not accessible

It should work. It’s our domain. Maybe you cannot access the Albania TLD? Sam can fix this easily… drone.cppalliance.org <http:// drone.cppalliance.org> should also work.

drone.cppalliance.org is Server Not Found for me.

To start, let’s catalog the possible solutions.

Gitlab

GitLab could work for me only as a self-hosted solution due to the accessibility issues I noted earlier. That is, only if the host is accessible.

On 11 May 2026 19:58, Sam Darwin wrote:

@Andrey, we should determine if the block is caused by DNS or TCP/IP. 1. ping drone.cpp.al <http://drone.cpp.al> . What are the results?

DNS works: 64 bytes from ec2-3-134-33-172.us-east-2.compute.amazonaws.com (3.134.33.172): icmp_seq=1 ttl=47 time=136 ms

2. Set /etc/hosts :  3.134.33.172 drone.cpp.al <http://drone.cpp.al> If the problem is DNS, /etc/hosts entry will solve it.  If the problem is IP, you need VPN access to Europe or the US.

I can access Drone via a VPN, but (a) VPNs are also not reliable here, they get blocked from time to time, and (b) starting up VPN every time I need to access Drone is a bit tedious.

On Mon, May 11, 2026 at 12:01 PM Sam Darwin via Boost <boost@lists.boost.org> wrote:

"I can access Drone via a VPN" "starting up VPN every time I need to access Drone is a bit tedious."

Is the problem the Albanian TLD or is it the IP address? Thanks

On 11 May 2026 19:29, Andrey Semashev wrote:

On 11 May 2026 19:24, Vinnie Falco wrote:

...

To start, let’s catalog the possible solutions.

Gitlab

GitLab could work for me only as a self-hosted solution due to the accessibility issues I noted earlier. That is, only if the host is accessible. On the topic of GitLab, it isn't looking good anyway as they are cutting staff and doubling down on AI usage for development.

https://about.gitlab.com/blog/gitlab-act-2/

On Tue, May 12, 2026 at 12:11 AM Andrey Semashev via Boost < boost@lists.boost.org> wrote:

On 11 May 2026 02:28, Vinnie Falco via Boost wrote:

...

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.

While I agree that GitHub availability and reliability has been going down in recent years, I can't tell whether the alternatives would be an improvement, in general or for me personally. I have no experience with Codeberg, and I don't know how reliable it is.

I assumed an alternative would be self-hosted. I don't think jumping to another provider is a long-term solution. github could be the official mirror, which also means that many people will clone from there, so we could offload some traffic.

On Thu, May 14, 2026 at 6:55 PM Glen Fernandes <glen.fernandes@gmail.com> wrote:

Something we host on git.boost.org

How do you open issues? Thanks