1. 79
    A new free-software forge: sr.ht vcs lwn.net

Seems like lwn is talking about @SirCmpwn’s sr.ht.

  1.  

  2. 17

    Composing a forge out of mini services + zero javascript needed on the web frontend seems very appealing, if only to a niche (of unknown size).

    1. 15

      For anyone who isn’t an LWN subscriber: https://lwn.net/SubscriberLink/775963/3cd82e9cbda2f293/

      1. 14

        My feelings are kind of mixed so far. The lightweight UI and responsive site are a breath of fresh air. What’s a little jarring is how much of the service is centered around email. I’ve never been part of a mailing list, and emailing code to other people sounds like something from 20 years ago, but maybe I’m just a young whippersnapper that doesn’t know what he’s talking about. Git is already a complicated tool, and adding email to the mix just increases the cognitive load. I’ll still learn how to use it because it sounds kind of interesting, but my preference would still be some kind of browser interface.

        1. 19

          I think you should give email a chance. Git has built-in tools for working with email and you can do your entire workflow effectively without ever leaving your terminal. Sending a patch along for feedback is just git send-email -1. (-1 meaning one commit, -2 meaning the last 2 commits, etc). Here’s a guide, which is admittedly terse and slated to be replaced with a more accessible tutorial:

          https://man.sr.ht/git.sr.ht/send-email.md

          That being said, web tools are planned to seamlessly integrate with this workflow from a browser.

          1. 11

            That being said, web tools are planned to seamlessly integrate with this workflow from a browser.

            I would use that.

            1. 4

              I like the email workflow, but I also have to be realistic - it is unlikely that my colleagues or drive-by contributors would adopt it. So, in practice it will mean fewer contributions and less cooperation.

              The GitHub-like workflow is something that is ingrained now and has a relatively low barrier to entry. So, if something is going to take over, it’s something that is very similar, such as GitLab or Gitea.

              Of course, there will always be projects that cater to an audience that feels at home with an email workflow.

              It’s good to hear that there will be web tools as well.

              1. 4

                I like the email workflow, but I also have to be realistic - it is unlikely that my colleagues or drive-by contributors would adopt it.

                I think as this workflow proliferates, this will become less and less true. It’s remarkably easy to make a drive-by contribution with email if you already have git send-email working, easier even than drive-by GitHub pull requests.

                1. 4

                  git send-email working

                  that’s a big ask

                  git send-email needs a bunch of perl packages, which often means you need to set up perl packaging.

                  Depending on your distro/OS this can be tricky, especially because git send-email needs a bunch of network packages and they don’t always cleanly install and you have to figure out why (except you don’t know much about perl packaging, so you can’t).

                  There have been multiple cases on different OSes (i think osx and some version of ubuntu) that i gave up after half an hour of various cpan commands trying to get things to work. I’m not even going to try setting that up on Windows.

                  Furthermore, the UX of git-send-email is terrible. Sending followup patches is annoying, for one.

                  All this has forced me to try and paste patches directly into an email client. But this is broken, too. GMail, for one, converts tabs to spaces in plaintext emails, breaking patches. I could use a local client, but setting up a client well is a lot of work and confusing (i could also rant for a while about why this is the case, but i won’t) and I don’t really want to switch my workflow over to using a client.

                  Furthermore, half the patch mailing lists I’ve worked with have hard-to-figure-out moderation rules. They’ll outright reject some kinds of emails without telling you, and because many are human moderated it’s hard to know if your email setup worked especially if you’re using git-send-email (which you may not have invoked or set up correctly) because 90% of the time your patch won’t show up on the list and you have no idea which of the many possible reasons for that is the case.

                  Despite all this I’ve submitted quite a few patches to a patch mailing list (hell, I’ve been involved enough in mailing-list-based project to have commit), either by lucking out on the perl setup for send-email, by temporarily setting up a client that doesn’t sync, or by sending patches through gmail with “ignore the whitespace please, that’s gmail’s fault, I’ll fix it when I commit”. It’s a chore each time.

                  I’ve given email multiple chances. It doesn’t work. The activation energy of email for patch contributions is quite high.


                  The web UI thing sounds like a good idea, especially if it can handle replies. It’s basically what I’ve been suggesting projects on mailing lists do for ages. Use email all you want, just give me a way to interact with the project that doesn’t involve setting up email.

                  1. 2

                    Almost no one has to package git’s perl dependencies themselves. Doesn’t your OS have a package for it already? And as someone who has packaged git before, it wasn’t really that bad.

                    Also, the golden rule of emailing patches is never paste them into some other mail client.

                    1. 2

                      Also, the golden rule of emailing patches is never paste them into some other mail client.

                      Paste not, but maybe attach? FreeBSD don’t like it, but it’s OK for Postgres.

                      1. 2

                        I generally prefer that people don’t attach patches, either. IMO the best way to send patches is send-email.

                        1. 1

                          “IMO” and “the best” is perfectly fine. But I was under impression that it was unconditionally the only way to submit patches, when I wanted to improve sr.ht’s PG DB schemas.

                          1. 2

                            Each project on sr.ht can have its own policies about how to accept patches. sr.ht itself does require you to submit them with send-email (i.e. for patches to the open source sr.ht repositories).

                            1. 1

                              Can you elaborate on what you dislike about sending patches with a normal MUA? It’s certainly a lot easier for someone who has spent the time to configure their MUA to be able to re-use the config they’ve already got rather than configuring a new tool they’ve never used before.

                              1. 3

                                The main issue is that nearly all MUAs will mangle your email and break your patches, which is annoying for the people receiving them and will be more work for you in the long run. Also, most end-user MUAs encourage the use of HTML emails, which are strictly forbidden on sr.ht. Also, code review usually happens by quoting your patch, trimming the fat, and replying inline. This is more annoying if you attach your patch to the email.

                                Setting up git send-email is pretty easy and will work every time thereafter. It’s also extremely convenient and fits rather nicely into the git workflow in general.

                                1. 1

                                  I see; so it has more to do with the fact that you can’t trust most popular MUAs not to screw up the patch rather than any inherent problem with that flow. For a well-behaved MUA it should be fine, but assuming a MUA is well-behaved (or even assuming that a user knows whether theirs is or not) isn’t a good bet.

                                  Thanks.

                      2. 1

                        Almost no one has to package git’s perl dependencies themselves. Doesn’t your OS have a package for it already?

                        No, i don’t mean you have to package them, but you have to install them and the installation isn’t always smooth. It’s been a while since I did this so I don’t remember the precise issues but i think it has a lot to do with the TLS part of the net stack. Which kinda makes sense, openssl packaging/linking has issues pretty much everywhere (especially on OSX).

                        Also, again, Windows. A lot of devs use Windows. I got involved in open source on Windows, back when I didn’t have my own computer. I could use Git and Github, but I’m pretty sure I’d have been unable to set up git-send-email if I had to at the time. Probably can now, but I’m an experienced programmer now.

                        Also, the golden rule of emailing patches is never paste them into some other mail client.

                        I know, except:

                        • now handling replies is annoying
                        • now i need to set up git-send-email, which doesn’t always work
                        1. 1

                          Windows devs aren’t in the target audience. I heard from a macOS user that they were able to get send-email working without too much trouble recently, maybe the situation has improved.

                          now handling replies is annoying

                          Not really?

                          now i need to set up git-send-email, which doesn’t always work

                          git send-email will always work if your email provider supports SMTP, which pretty much all of them do.

                          1. 1

                            Windows devs aren’t in the target audience

                            If you’re wishing for email to be the future, you’re going to have to think about windows devs at some point.

                            (this choice is also even more hostile to new programmers, as if patch email workflows weren’t newbie-hostile enough already)

                            Not really?

                            You have to copy message ids and stuff to get lists to thread things properly

                            git send-email will always work

                            I just told you why it doesn’t always work :)

                            1. 3

                              I’m prepared to lose the Windows audience outright on sr.ht. Simple as that.

                              (edit)

                              Regarding message IDs, lists.sr.ht (and many other email archives) have a mailto: link that pre-populates the in-reply-to for you.

                              1. 1

                                I’m prepared to lose the Windows audience outright on sr.ht. Simple as that.

                                oh, sure, for your own tool it’s fine.

                                what I’m saying is that if you’re expecting this workflow to proliferate you will have to deal with this too.

                                Do whatever you want with your own tool: I’m just explaining why send-email proliferating is a tall order, and windows is a major draw here.

                                Regarding message IDs, lists.sr.ht (and many other email archives) have a mailto: link that pre-populates the in-reply-to for you.

                                ah, that’s nice. I may not have encountered lists with this (or been interacting only by email and not using the archive)

                      3. 1

                        git send-email needs a bunch of perl packages, which often means you need to set up perl packaging.

                        Personally I’ve never once seen a unix machine where the perl stack wasn’t already installed for unrelated system-level stuff.

                        1. 1

                          to be clear, perl is usually installed, it’s the relevant packages (specifically, the networking/TLS stuff) that usually aren’t

                          this is particularly bad on OSX which has its own openssl issues, so the Perl SSL packages refuse to compile

                      4. 4

                        if you already have git send-email working

                        Sadly, I think this is extremely uncommon :’(

                        1. 3

                          Hence:

                          I think as this workflow proliferates

                          1. 5

                            I think I’d phrase this as if it proliferates, as if anything I think the number of people with sendmail (or equivalent) working on their computer is going down, not up. It’d be fun to see it rise again due to sr.ht, though I don’t know that I’m optimistic. But perhaps I’m just being overly pessimistic :)

                            I do worry about more casual developers though, who may not even really know how to use the command-line. I think an increasing number of developers interact with version control solely through their IDE, and only touch their command-line if they have to copy-paste some commands. It’d be interesting to see if that’s something this workflow can still cater to. Some simple web-based tooling may go a long way there!

                            1. 3

                              You don’t need to set up sendmail, you just need a mail server with SMTP - which nearly all of them support.

                              1. 3

                                Sorry, what I meant was more that you have to set up git for e-mail sending. I happen to have sendmail already set up, so all I needed was git config --global sendemail.smtpserver "/usr/bin/msmtp", but I think it’s very uncommon to already have it set up, or to even be comfortable following the instructions on https://man.sr.ht/git.sr.ht/send-email.md.

                      5. 2

                        I like the email workflow, but I also have to be realistic - it is unlikely that my colleagues or drive-by contributors would adopt it. So, in practice it will mean fewer contributions and less cooperation.

                        The great thing about this is it’s not all-or-nothing.

                        For https://fennel-lang.org we accept patches over the mailing list or from GitHub pull requests. Casual contributions tend to come from GitHub, while the core contributors send patches to the mailing list and discuss them there. Conveniently, casual contributions tend to require less back-and-forth review, (so GitHub’s poor UI for their review features is less frustrating) while the big meaty patches going to the mailing list benefit more from the nicer review flow.

                      6. 3

                        … that is if you’ve managed to set it up in the first place, probably without an opportunity to test it – that means that you have send your commit, not knowing what will come out, to test your setup, your configuration and the command you chose in the first place, which puts quite a lot of pressure, especially on people who have little experience with projects, let alone email-projects.

                        That being said, web tools are planned to seamlessly integrate with this workflow from a browser.

                        very nice.

                        1. 2

                          Nah, on sr.ht I have an open policy of “if you’re unsure about your setup, send the patch to me (sir@cmpwn.com) first and I’d be happy to make sure it’s correct”.

                          1. 2

                            I wonder if it would make sense to set up a “lint my prospective patch” email address you could send your patch to first which could point out common mistakes, assuming that kind of thing is easy to write code to detect.

                            1. 2

                              I plan on linting all incoming emails to lists.sr.ht to find common mistakes like this and reject the email with advice on how to fix it.

                              1. 1

                                If you can get this running well and cheaply, you could potentially do an end run around people’s send email setup related issues by hosting a “well formed, signed, patches-only” open email relay, and local git config instructions.

                            2. 1

                              Is there a way or a plan to have a patch-upload form for example? That might be helpful for beginners.

                              1. 3

                                Yes, I plan on having a web UI which acts as a frontend to git send-email.

                        2. 4

                          I like that it’s using e-mail so it’s “federated” and decentralized by default.

                          The e-mail workflow has two problems though:

                          • integrations: usually projects have a lot of checks that can be automated (“DCO present”, “builds correctly”), for e-mail workflow this kind of stuff needs to be built (check out how Postgres does it),
                          • client configuration: to correctly use this workflow, one need to configure git send-email (setting up credentials for example), project configuration (correct sendemail.to and format.subjectprefix) and e-mail client to send plain text, 72-characters wrapped messages. Apparently not everyone does that.

                          Mailing lists vs Github nicely summarizes benefits of ML over Github but also highlight the number of things maintainers need to setup to run their projects on ML that Github gives them “for free”.

                          From my point of view sr.ht looks like a great way to validate the idea if it’s possible bring easy project collaboration from Github to MLs.

                          1. 2

                            usually projects have a lot of checks that can be automated

                            This is planned on being addressed soon on sr.ht with dispatch.sr.ht, which is used today to allow GitHub users to run CI on builds.sr.ht. The same will be possible with patches that arrive on lists.sr.ht.

                            client configuration

                            There’s a guide for send-email:

                            https://man.sr.ht/git.sr.ht/send-email.md

                            As for other emails, I’m working on some more tools to detect incorrectly configured clients and reject emails with advice on how to fix it.

                            Thanks for the feedback!

                            1. 2

                              I’m really interested in how far can one push this model.

                              Would it build the patch and e-mail back build results? For example with a link to build results and a quick summary?

                              Are you also planning for some aggregation of patches? (Similar to what Postgres has). For example Gerrit uses Change-Id to correlate new patches that replace old ones. Would you for example use Message-Id and In-Reply-To with [Patch v2] to present a list on a web interface of patches that are new / accepted / rejected? This interface could be operated from e-mail too I think, e.g. mailing LGTM would switch a flag (with DKIM validation so that the vote is not spoofed).

                              By the way I really like how sr.ht is challenging status-quo of existing solutions that just want to mimic GitHub without thinking about basic principles.

                              Good luck!

                              1. 7

                                Would it build the patch and e-mail back build results? For example with a link to build results and a quick summary?

                                Yep, and a link to a full build log as well.

                                Would you for example use Message-Id and In-Reply-To with [Patch v2] to present a list on a web interface of patches that are new / accepted / rejected?

                                Yep!

                                This interface could be operated from e-mail too I think, e.g. mailing LGTM would switch a flag (with DKIM validation so that the vote is not spoofed).

                                Aye.

                                1. 3

                                  Great!

                                  By the way I admire you pro-active approach of not only explaining the problem but also building beautiful software that solves the problem! 👍

                          2. 3

                            emailing code to other people sounds like something from 20 years ago

                            At least OpenBSD is still doing that on the regular on the tech@ mailing list. It definitely still works.

                            1. 2

                              And I love it. It’s so damn easy to just email a one-off diff and watch someone land it. No accounts, no registration, no forking repos and dealing with fancy weird web UIs…

                            2. 3

                              One day, the current generation of “Email is SO 5 minutes ago!” kids are going to wake up and realize that e-mail is an amazing tool.

                              Or so I’d like to think :)

                              1. 1

                                I could be convinced. What’s your argument in favor of email?

                                1. 3
                                  • Inherently de-centralized
                                  • Can be tuned for nearly real time end to end response of low bandwidth batch processing for where network is at a premium
                                  • Vendor neutral
                                  • As rich or as minimal as you want it to be
                                  • Arbitrary context types - you can send everything from 7 bit ASCII to arbitrarily complex HTML/CSS and varying payload types
                                  • Readable with everything from /bin/cat to a nice client like Thunderbird and everything in between
                                  • Rich capabilities for conversation threading
                                  • Rich search capability client and server side
                                  • Myriad archival and backup options

                                  The list goes on.

                                  For a more end user/business-centric version of this see In Defense of Email

                            3. 7

                              As far as I can see here this won’t be shared by many and it may sound harsh, but the UI just doesn’t look appealing to me at all. Take for example https://man.sr.ht/git.sr.ht/send-email.md it’s not clear where the content of the “file” send-email.md starts and where the menu is. (Talking about “safe zone” of user content vs site navigation etc) Or Tickets: https://todo.sr.ht/~sircmpwn/sr.ht/112 I was just lost at first, until I recognized that the right part are comments?! and the left is the real “content” of the ticket. Also the font of the top navigation is far too big. My eyes just don’t want to grasp the “user/project/#issue - title” sequence, it’s too bloated.

                              Also in my thousands of commits I’ve never used email to send code around. These days I’m amazed when people are able to use email without their browser open.

                              Having no centering is kinda bad. Github also manages to work flawless when only half-sizing your window, so the left-positioned site is no excuse in my eyes.

                              I wish you the best of luck as gitlab is already too bloated for a distributed replacement of github.

                              1. 13

                                @sircmpwn, please please please put a style="margin: auto;" or similar fix on the root container for the content in the pages. No centering in this day and age is kinda unforgivable.

                                1. 10

                                  Many people, myself included, appreciate the left-aligned layout. However, I can empathise with users of ultrawides etc. To that end this ticket exists:

                                  https://todo.sr.ht/~sircmpwn/sr.ht/112

                                  1. 12

                                    Okay, but seriously, look.

                                    This is on a 1920x1080 monitor.

                                    I’d buy the left-justification style preference, but:

                                    • You still have the top navbar going all the way across the screen.
                                    • You still have the right-hand toolbar ending up dead-center.

                                    Your design needs love.

                                    1. 8

                                      Okay, but seriously, look.

                                      Right. This is how it’s supposed to look. You could trivially center this with a user style if you feel strongly about it.

                                      I definitely appreciate the feedback, but I get more positive feedback on the design than negative.

                                      1. 3

                                        It’s your project, but even in the bug tracker you yourself linked only one person is clearly in support of keeping it left-aligned–at least 3 others seem to be against it (cos, benharri, lewis from the thread).

                                        Like, even if you don’t move the whole container to the center, at least make it use the entire screen–have the righthand stuff actually on the righthand side of the page, instead of awkwardly in the middle.

                                        1. 10

                                          That’s because I direct people who complain to this ticket, and I don’t direct anyone here who praises it.

                                          1. 13

                                            Fair enough. Also, lest I leave the impression I’m just picking nits on an otherwise difficult project–thanks for making your work on this open-source and getting it going. It’s a lot of work, and I’m betting people are getting good use out of it.

                                        2. 2

                                          Right. This is how it’s supposed to look. You could trivially center this with a user style if you feel strongly about it.

                                          The only problem I can see is that “Login/Register” is right aligned, so it ends up out of alignment with the bar on the right hand side.

                                        3. 7

                                          I agree that the login box sticking out to the top right looks broken.

                                          Also a utilities column on the right side of the left-justified page looks a bit weird, if going left-justified wouldn’t that look prettier along the left edge of the window, with a proper ragged right look?

                                          1. 1

                                            I feel like it wouldn’t be too bad of an issue if the login/register form was at the right, and possibly the pictures too.

                                            I don’t agree that the fix is as simple as centering everything, SirCmpwn has a vision that still needs to be respected, but the design just needs some more thought, and I don’t think it should be a big priority at this point in the development.

                                      2. 5

                                        | “Email is painful to set up and use any more—many are finding alternatives far more attractive.”

                                        …while many others are far happier with plain old email.

                                        1. 10

                                          I got so fed up with GitHub’s terrible comment boxes which override my key bindings to insert useless markdown snippets (the whole point of markdown is that you can write it by hand without any stupid editor help!) that I just started blocking their JS site-wide. Being able to reply to patches in my email client is a breath of fresh air!

                                          1. 3

                                            But you can reply to notification emails from GitHub in your email client.

                                            I still agree with you about the editor “help”, which is what you’re really complaining about…

                                            1. 1

                                              True; you can reply to notifications in the top-level context of a pull request, but you cannot comment on specific parts of a patch without using the web UI. This is a pretty core requirement for a code review flow, so having the whole patch in the email thread is needed for doing this outside the browser.

                                              1. 1

                                                Ah, yeah, that’s true.

                                                1. 1

                                                  Isn’t there something that (will?) allow magit to do this?

                                                  edit: magit-review works for gerrit. I can’t seem to find anything that’ll do this generally.

                                                  1. 1

                                                    I’m using an old version of magit from 2012 before they added a bunch of annoying features and moved around the key bindings I use. But if it could allow me to do code review on dayjob projects without using the browser that’s the one thing that could get me to pull in a newer version.

                                                2. 1

                                                  But you can reply to notification emails from GitHub in your email client.

                                                  Doesn’t work that great though. For PRs, it will always append the message to the general comment thread, instead of the thread the comment was on. For issues it works a bit better, but it’s best to remove the quoted part (many don’t) as GitHub won’t remove it. It’ll try and hide it with some JS, but I’ve seen that fail.

                                            2. 2

                                              I signed up the other day after @kotrunga posted a link in the GitHub free private repos thread.

                                              Can’t say I’ve used it much yet, except adding a single repo, but I like the idea, and I’m looking forward to moving over some projects from GitHub and giving it a try.

                                              1. 1

                                                nice!

                                                1. 3

                                                  I don’t even a single repo on it yet, but I wanted to fund true FLOSS and its developers like @SirCmpwn (put money where your mouth is, etc.), so I got an year’s subscription. I hope to keep renewing subscriptions for many years to come.

                                                  1. 3

                                                    I paid for it because of what it could become. I probably won’t really use it until it has a browser-based workflow for code review and issues and such, but once that exists it could be an incredibly pleasant tool to use.

                                                    1. 2

                                                      Thank you <3

                                                2. 1

                                                  I’m intrigued by the claim that builds.sr.ht is “the only platform which can scale to the automation needs of an entire Linux distribution.” What makes it so much more powerful than anything else out there?

                                                  1. 2

                                                    One big issue is that it runs builds with KVM. Travis, for example, runs everything in Ubuntu and anyone working on a different distro has to set up a chroot in every build. Something like Jenkins might work because you can customize it more, but you would basically have to build what builds.sr.ht already does on top of Jenkins. Also, non-Linux support is very rare, and sr.ht theroetically supports any kernel and already supports FreeBSD (as such, some ports maintainers are using builds.sr.ht for CI becuase no other platform supports FreeBSD).

                                                    builds.sr.ht also functions as a standalone build “engine” without necessarily being a full CI platform, and requires glue from integrations like git.sr.ht and dispatch.sr.ht to provide a full solution. But if you peel that glue back and replace it with your own glue, like for example postmarketOS does, you can get a system more flexible than any other and build some pretty cool automation around it.

                                                  2. 1

                                                    “Subscription required”

                                                    1. 2

                                                      Heh, sorry, I forgot putting the subscriber link, see @azdle comment, or if any mod can update the link.

                                                    2. 1

                                                      Anyone knows how to pronounce “sr.ht” or what it means? (I saw this question a few times but never an answer, though I guess the answer must be there somewhere)

                                                      1. 4

                                                        Sir Hat (or any other way you want). From https://drewdevault.com/2018/11/15/sr.ht-general-availability.html