Fediverse@lemmy.worldbythann@lemmy.dbzer0.com
9 months

GitLab abandons federation plans!

gitlab.com English

After 5 years of foot-dragging they finally close the ticket to community protest:

This feature request is being closed as our current focus isn’t in this area.

We appreciate your input and contribution to improving our product. While this feature may have merit, we need to prioritize our efforts elsewhere at this time.

If you’d like to provide additional context about why this feature is important, please feel free to leave a comment on this issue. This will help us better evaluate the feature if we revisit this area in the future.

Thank you for your understanding and continued support in helping us build a better product.

9
    Support ActivityPub for GitLab (#11247) · Epics · Epics · GitLab.org · GitLab
    gitlab.com
    Gitlab/ActivityPub Design Documents by @oelmekki The goal of those documents is...
    • QuazarOmega@lemy.lolEnglish
      9 months

      That sucks majorly, I knew GitLab isn’t our friend, but to plain dismiss a development effort that didn’t even come from their own employees is just spitting in our face.
      Forgejo federation can’t come any sooner ✊

    • NuXCOM_90Percent@lemmy.zipEnglish
      9 months

      For those who were out of the loop:

      What exactly is the idea of federated gitlab? Git is already inherently distributed and automagically mirroring to other remotes is generally like three lines in any CI syntax (and there is probably a precommit hook for it too).

      Also: I can see a LOT of security issues with not having a centralized source of truth on what the commit hashes should be and so forth. is fedgit dot zip the source of truth for this app or fedgit dot ml or fedgit dot ca? Theoretically that is where signing comes into play but that gets back to: What advantage does a “fediverse” frontend have?

      • green_copper@kbin.earth
        9 months

        I think the federation was more about interacting with other instances. Like creating issues and pull-requests without needing to create a new account for every instance.

        I think this would be useful, as reporting bugs on GitLabs can be annoying if you have to create an account first.

        • NuXCOM_90Percent@lemmy.zipEnglish
          9 months

          As one of the core contributors for even a moderately sized project on Github: HELL NO.

          We already get more than enough drive by spam from everyone who just makes an account to complain that our code doesn’t do something we never said it did. And if they don’t even have to do that? Ugh.

          I do firmly believe that more projects need to understand the implications of where they host something (similar to the IOS app that alerts you if ICE is in your area). But if someone can’t be bothered to even use a throaway protonmail address to file a bug report or feature request? Quite frankly, what they have to say wouldn’t have been worth our limited time anyway.

          • cecilkorik@lemmy.caEnglish
            9 months

            But if someone can’t be bothered to even use a throaway protonmail address to file a bug report or feature request? Quite frankly, what they have to say wouldn’t have been worth our limited time anyway.

            You don’t know that, because you’ve never once heard what someone didn’t say. Their time is limited too.

          • Ademir@lemmy.eco.brEnglish
            9 months

            We already get more than enough drive by spam from everyone who just makes an account to complain that our code doesn’t do something we never said it did. And if they don’t even have to do that? Ugh.

            That’s easy to solve by allowing no one to open issues at all. JK.

      • Raphael@communick.newsEnglish
        9 months

        What advantage does a “fediverse” frontend have?

        Github’s dominance comes from the network effects. Everyone’s on github, so if you have your project on a different repo, you won’t get as many visibility. If your project is on gitlab only and someone wants to report a bug, they need to:

        • Find your instance.
        • Create an account.
        • Deal with an unfamiliar interface
        • Create the ticket
        • Hope it gets seen.
        • Potentially forget about it, unless they set up notifications.

        A Federated forge solves all of that.

        • You follow remote projects without having to create an account in the remote instance.
        • You open an issue on the remote forge without having to open in an account in the remote instance, and you do it from your local server.
        • If you have a PR ready, the remote instance gets notified.
        • It makes a lot easier to separate CI/CD from source management.
        • It makes a lot easier to separate source management from issue tracking.
        • etc
        • etc
        • etc
      • Aatube@kbin.melroy.org
        9 months

        Every GitLab instance requires you to have an account there to comment and submit PRs. Projects are often hosted on different instances.

      • Russ@bitforged.spaceEnglish
        9 months

        I always assumed it was more or less targeting the federation of issues/MRs.

        The git side of things is already distributed as you said, but if you decide to host your random project on your own GitLab instance you’ll miss out on people submitting issues/MRs because they won’t want to sign up for an account on your random instance (or sign in with another IdP).

        This is where a lot of the reliance of GitHub comes from, in my opinion.