Re: GitHub reliability

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/