Re: GitHub reliability

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 <
[email protected]> 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 <
> [email protected]> 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 -- [email protected]
> > To unsubscribe send an email to [email protected]
> > https://lists.boost.org/mailman3/lists/boost.lists.boost.org/
> > Archived at:
> >
> https://lists.boost.org/archives/list/[email protected]/message/XLH3UJ65KVKARUAQFCSFAPOUTLXYN4JI/
> >
> _______________________________________________
> Boost mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> https://lists.boost.org/mailman3/lists/boost.lists.boost.org/
> Archived at:
> https://lists.boost.org/archives/list/[email protected]/message/4OKKCF5US4WZXXC4WFMNMSFAA5KIHISO/
>
_______________________________________________
Boost mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://lists.boost.org/mailman3/lists/boost.lists.boost.org/
Archived at: https://lists.boost.org/archives/list/[email protected]/message/JKVK5KZ6PUL53UUCWXSV4FEQY6MN2DLB/