Bitbucket removes issues and wikis

[Andrey Somov]

Dear all,

because Bitbucket removes issues and wikis, we may migrate to another home.

Stay tuned.

(it is the second major hit - the first was Mercurial removal)

Cheers,

Andrey

[Toolforger]

I try to put everything - issues, wikis, whatnot - into the git
repository itself, one way or the other, to avoid scenarios exactly like
these.
I.e. don't rely on third-party services, except for
universally-available features (e.g. git branches) and ephemeral things
(e.g. brainstorming pages).
Downside is that all collaboration needs to go through a git push,
though I guess most people who use Snakeyaml can adopt to this style.

I'd like to recommend something that's easy to self-host, but GitLab is
really large and requires work, and Gitea (and its later forks,
including Forgejo) have areas that nobody maintains anymore, so security
and reliability tend to be sketchy, and you need to take a burden of
site maintenance.
I found some suggestions searching for
easy foss alternative to atlassian
but don't have experience with any of them.
Maybe other searches can turn up better results.

HTH
Jo

Am 27.03.26 um 07:31 schrieb Andrey Somov:

[mfried...@gmx.de]

Hi,

maybe take a look into https://codeberg.org/. This is a forgejo instance provided by a German non-profit organization (https://docs.codeberg.org/getting-started/what-is-codeberg/#what-is-codeberg-e.v.%3F).
For a single project this looks to be a good solution.

Mit freundlichen Grüßen
Mirko Friedenhagen
--


Am 27.03.26 um 11:09 schrieb Toolforger

> --
> You received this message because you are subscribed to the Google Groups "SnakeYAML" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to snakeyaml-cor...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/snakeyaml-core/020af7a1-1efa-47f3-8615-f056ce89ab93%40durchholz.org.
>

[Toolforger]

> maybe take a look into https://codeberg.org/. This is a forgejo instance provided by a German non-profit organization (https://docs.codeberg.org/getting-started/what-is-codeberg/#what-is-codeberg-e.v.%3F).
> For a single project this looks to be a good solution.

Actually, now that I had time to think about it some more, I'd like to
warn against self-hosting in any way where hackability is even a remote
possibility.

Snakeyaml has become a well-known library - it's inside of Spring, it
has pages on Baeldung that the library author didn't write.
And it's maintained by a single guy (essentially). Somebody who even
does not do a daily check, and let spammers go rampant on the mailing
list for months (not Andrey's fault by any means!)
That's *exactly* the demographic that malware distributors all over the
world want for supply-chain attacks. It's what happened to the XZ
maintainer, who was tricked into allowing a well-hidden binary blob into
his build system.
Even a second maintainer isn't a guarantee - in the XZ case, the second
maintainer was the guy who actually injected the malware...

Now, Forgejo is a fork of Gitea, and the Forgejo people say that Gitea
is full of bugs (which means it's full of security holes) and that they
haven't fixed them all. One guy indirectly said it's unlikely that they
will ever be able to catch up.
I wouldn't want to use that kind of software to host anything that's a
plausible target for a secret service!

For my own projects, I actually stopped using any interactive web software.
I have a git repository, a bunch of static HTML pages (which I generate
offline from source files and upload), and there's a mail address that
people can send feedback, and that's it.

If that's too frugal for Snakeyaml, you want to host it on some large
company that can afford to pay a security team.
You want to avoid lock-ins, so no CI servers (that can be done offline,
which is even safer if you provide instructions so everybody can build
offline), no company-provided services except for ephemeral stuff that's
understood won't be archived - e.g. you could have patch discussions,
but the patches and the issues that explain why the patch was done need
to live inside git, not on a foreign server.

Just my 2 cents.
Well, maybe more than that, this message became another wall of text -
sorry for that.

Regards,
Jo