• Boud@framapiaf.org
    link
    fedilink
    arrow-up
    1
    ·
    2 years ago

    @sugar_in_your_tea As a non-lemmy-dev, I don’t get to participate in that decision either, no matter how strong I think the arguments are.

    I’m not convinced that the difficulty in switching is low; as you say, bug/issue tracking is a big barrier, but other features are part of the #EEE strategy [4], and switching later when MS upsets the community like Musk or Huffman will be difficult.

    An official mirror would be a good start to make a future move easier.

    @lemmy

    [4] https://en.wikipedia.org/wiki/Embrace%2c_extend%2c_and_extinguish

    • nutomic@lemmy.mlOPM
      link
      fedilink
      arrow-up
      4
      ·
      2 years ago

      There are mirrors of the Lemmy code on Gitea and Gitlab. They are linked in the readme. We also hope to migrate development to Gitea once federation is implemented.

      • PureTryOut@lemmy.ml
        link
        fedilink
        arrow-up
        2
        ·
        2 years ago

        We also hope to migrate development to Gitea once federation is implemented.

        That is awesome to hear! Lemmy federating with the code forge it’s hosted on sounds awesome!

        • nutomic@lemmy.mlOPM
          link
          fedilink
          arrow-up
          1
          ·
          2 years ago

          Im not talking about federation between Lemmy and Gitea. Not sure how that would work or if it would make sense.

          • PureTryOut@lemmy.ml
            link
            fedilink
            arrow-up
            1
            ·
            2 years ago

            I get that but it still sounds awesome 😉 Of course Gitea federating with other Gitea (or Forgejo) instances would be awesome and make it a right candidate to host another fediverse project.

    • sugar_in_your_tea
      link
      fedilink
      arrow-up
      1
      ·
      2 years ago

      It’s really not that difficult. The things that need to be migrated are:

      • links to repository - tedious, but the GH repo could be left up with links to the new repo and code mirroring could be configured; I’ve seen that done pretty often, and some projects go the opposite route (e.g. the Linux kernel has a GitHub mirror for… reasons)
      • issues - the GitHub CLI and API both offer a programmatic way to pull down issues, so those can be migrated with a script to whatever the new solution is; I could whip something up in an afternoon if needed
      • actual code hosting - just change remotes and push; this is like a 5-min thing
      • CI - the current CI situation is really simple and easy to port

      And, that’s it. If needed, the whole process could be done in a couple days.

      So I don’t see any kind of urgency here.