FFmpeg
code.ffmpeg.org
FFmpeg
  • Victor@lemmy.world
    21·
    15 hours ago

    How do you really pronounce Forgejo? Like, I wanna say it’s like a Spanish kind of thing like “For-gheh-hoh”?

  • clb92@feddit.dkEnglish
    37·
    18 hours ago

    What did they use before? GitLab? A hosted solution like GitHub or Codeberg?

      • clb92@feddit.dkEnglish
        281·
        18 hours ago

        I’m probably gonna sound like a noob now, but how does one even properly handle issue tracking, working like that?

        • psycotica0@lemmy.ca
          802·
          16 hours ago

          I’m not an ffmpeg maintainer, but it’s actually not as hard as you think. You know how when you get an email it shows up in your list of emails? That’s your list of issues.

          You know how when you get a reply to an email, all email clients that aren’t the most absolutely basic will put the original emails and its replies into a thread together? That’s the conversation about an issue, in context, with threading.

          You know how emails can have attachments? That’s attachments. You can put screenshots in there, or patches, lots of stuff.

          Now you may be wondering, that sounds like a lot of emails. That’s true! But most people who live the mailing list life have filters and stuff setup to expect a lot of unsolicited emails. Like there are headers in the emails from mailing lists that tell you which list it was from, so it’s really trivial to have a thing that puts all mail from this list into a folder or something and then not notify on emails in that folder. So, like an issue page, you can check it periodically, maybe mark certain ones as notification worthy, and ignore the rest.

          The main upside to this is that the theoretical barrier to entry is relatively low, because every human who has touched a computer basically has an email. And you can have ultimate control of your experience because really it’s all about what features your mail client has. And even if the mailing list server goes down you won’t get any new emails, but you already have all the emails you’ve received before, so it’s distributed! And you can still send replies while it’s down, and they’ll just spool until things come back up. Magic!

          The main downside is that the practical barrier to entry is relatively high because people aren’t used to joining mailing lists and aren’t setup for it, and so it ironically feels like a much bigger deal, if you’re any “normal” kind of email user, than creating a new username and password account. So for casual users, it’s kind of a nightmare.

          Also, because mailing lists are usually public, it’s really easy to make a web frontend that contains the archive for non-subscribers and search engines and stuff, but while these could look like anything, in practice they look like ass, because mailing list people don’t really care about what web stuff looks like a lot of the time. Which makes sense, they’re not looking at the web frontend, they’re ssh’d into a jump box using mutt through screen, or some set of emacs plugins 😛

          • youmaynotknow@lemmy.zip
            2·
            6 hours ago

            And now, thanks to you, I’m no longer afraid of starting to leart git, and then hosting my own forgejo instance for my Obsidian and other things. Thank you.

            This is the best clarification of git I have ever seen, and I’ve seen a lot.

          • clb92@feddit.dkEnglish
            16·
            15 hours ago

            Awesome and detailed explanation, thanks. I figured they’d be juggling a lot of mails, and I guess it is possible for some people to stay on top of that and keep it all organized with a good mail client, but still… I would get lost so quickly.

            Thanks again!

            • u_tamtam@programming.dev
              2·
              6 hours ago

              I figured they’d be juggling a lot of mails

              Yeah, but organized into as many threads as there are issues/PRs, so it’s exactly as daunting as the same list as viewed on GitHub/project/issues (because it is exactly the same content).

              and I guess it is possible for some people to stay on top of that

              It’s the crux of being a maintainer, it’s your job “to stay on top of that”, with, on larger projects, ad-hoc tooling and automation being the only way. Email is infinitely more flexible than the one-size-fits-all take by GitHub on that.

          • dizzy@lemmy.ml
            4·
            14 hours ago

            Thanks for explaining this all! Super interesting thing that I knew existed but had no idea how it worked! Makes a lot of sense!

        • Clot@lemmy.zipOPEnglish
          172·
          18 hours ago

          I wonder the same

          Only ancient people can tell that

          • WhatAmLemmy@lemmy.worldEnglish
            11·
            17 hours ago

            It’s like people who manage their tasks by simply writing them down on paper…

            You fucking what!?! How am I supposed to manage hundreds of tasks with a piece of paper… They won’t fit. What if I lose the paper? How do I filter the tasks by location, date, time, or any other context? Your ancient methods are pure insanity to me.

            • Jo Miran@lemmy.ml
              52·
              17 hours ago

              Bullet Journal. It’s the only method that works with my ADHD and keeping it analog allows me to “other” the journal away from the clutter.

    • 0_o7@lemmy.dbzer0.comEnglish
      17·
      18 hours ago

      Seems like just git with a mailing list and a mirror on github.

      Patches should be submitted to the ffmpeg-devel mailing list using git format-patch or git send-email. Github pull requests should be avoided because they are not part of our review process and will be ignored.

  • Zenlix@lemmy.ml
    13·
    17 hours ago

    It seems a bit off that the only accept code via mail but host the repo with forgejo and have a lot of open PRs.