And even being understaffed and underfunded would at least be understandable, but some of these problems have been caused by the completely unnecessary upgrade of Lemmy to a non-stable branch.
That was possibly done to recover locked-out users. Lemmy 0.19.x switched to SHA-1 for 2FA from SHA256 and added TOTP verification for enabling 2FA. Since SHA256 isn’t supported by many authenticator apps, only generating invalid tokens, it left many users locked-out. Doing the upgrade disabled previously enabled 2FA. So it makes sense. lemmy.ml is also on RC, by the way.
Sure, but the idea of running, monitoring and supporting the (final) RC on lemmy.ml is to see how it performs under real life conditions, before letting it loose in the wild. And it was properly announced beforehand. This is quite different from what SDF did with this instance.
And even being understaffed and underfunded would at least be understandable, but some of these problems have been caused by the completely unnecessary upgrade of Lemmy to a non-stable branch.
That was possibly done to recover locked-out users. Lemmy 0.19.x switched to SHA-1 for 2FA from SHA256 and added TOTP verification for enabling 2FA. Since SHA256 isn’t supported by many authenticator apps, only generating invalid tokens, it left many users locked-out. Doing the upgrade disabled previously enabled 2FA. So it makes sense. lemmy.ml is also on RC, by the way.
Sure, but that is the instance specifically run by the Lemmy developers.
Sure, but it’s a regular instance. They do have one that’s primarily for testing, voyager.lemmy.ml.
Sure, but the idea of running, monitoring and supporting the (final) RC on lemmy.ml is to see how it performs under real life conditions, before letting it loose in the wild. And it was properly announced beforehand. This is quite different from what SDF did with this instance.