1. 96

Came across this recently - it describes itself as “the open source software suite for managing your software development projects that you’ve been waiting for”, and purports to be an indev GitHub alternative that’s 100% FOSS and email-driven.

  1.  

  2. 16

    Thanks for posting this, eta! sr.ht is still a work in progress, but things are definitely starting to fall into place. The whole thing is self hosted (it even deploys itself on the in-house CI) and it’s being used seriously for a few projects - we run all builds for the sway and wlroots projects through it, for example: https://builds.sr.ht/job/4878.

    Check out https://lists.sr.ht/~sircmpwn/sr.ht-announce for news, or shoot an email to ~sircmpwn/sr.ht-announce+subscribe@lists.sr.ht. If anyone from Lobsters wants an alpha account, shoot me an email - sir@cmpwn.com - would be happy to hook you up.

    1. 7

      I’m impressed that you not only develop end-user software (sway) and its libraries (wlroots), but you also build out the whole project lifecycle tools as well. How do you find the time to do everything? Do you have any productivity advice for others on managing and delivering so many different projects?

      1. 19

        Thank you for your kind words! It might be prudent to point out that neither sway, wlroots, nor sr.ht has seen a stable release to date, though. I’m not afraid to start a lot of ambitious projects, even if they’ll take years to complete, because the years will eventually pass and I’ll thank myself for not spending them worried I wouldn’t have had time to complete anything. At least how I hope it works, we’ll see if any of this shit ever gets done!

    2. 6

      I still don’t get why sending patches via email is preferable over creating git remotes and pulling changes from them, the latter seems to fit better into git’s decentralized model. Even if you have scripts to create emails out of patches and apply them, it still seems clunky to try to recreate git’s state over text.

      1. 7

        The main advantage of email is that you can do code review over email, too - you can chop up the patch and reply to specific lines of code inline and carry on the discussion same way you would any other email thread.

        For bigger changes, though, it doesn’t scale. For that, we have git request-pull:

        https://www.git-scm.com/docs/git-request-pull

        I intend to facilitate both approaches on sr.ht.

        1. 2

          Email simplifies things.

          You don’t need to know git ;)

        2. 3

          Even if you have scripts to create emails out of patches and apply them, it still seems clunky to try to recreate git’s state over text.

          Git was made with email workflows in mind from the start. To send email, git helps with git format-patch and git am can receive patches via email. The patch format, for that matter, was also made with email in mind.

        3. 4

          Just git?

          I was kind of hoping that if we’re going to break the github hegemony, we might also start to reconsider git at least a little. Mercurial has so many good ideas worth spreading, like templates (DSL for formatting the output of every command), revsets (DSL for querying commits), filesets (DSL for querying files and path) and changeset evolution (meta-graph of commit rewriting).

          1. 9

            Don’t forget pijul!

            Seriously, though, I don’t think there is any “github plus something” that is going to break the github hegemony. Github won because it offered easy forking while Sourceforge was locked in a centralized model. Sourceforge won because it was so much easier than hosting your own repo + mailing list.

            The thing that will get people away from github has to have a new idea, a new use case that isn’t being met by github right now, and which hasn’t been proposed before. That means that adding hg won’t do it – not because hg is worse than git (honestly, git’s terrible, and hg is fine), but because hg’s already been an option and people aren’t using it.

            Adding email commits won’t do it, because that use case has been available for a long time (as pointed out elsewhere in these comments) and people aren’t using it.

            Until something new is brought to the table, it’s all “let’s enter a dominated market with a slight improvement over the dominant tech”, and that’s just not going to be enough.

            1. 7

              So, one thing that I would use a new contender for is being able to put my work under my own domain.

              The “new thing” here is “have your personal branding on your site” (which is clearly fairly popular given how common personal domain/sites are among developers).

              If I could CNAME code.daniel.heath.cc to your host to get my own github, I’d do it today (as long as any issues/wiki/PR state/etc remained usefully portable).

              1. 7

                That’s a really neat idea. I don’t think I can prioritize it right now but it’s definitely something I would consider implementing.

                1. 3

                  I actually think that GitHub’s lack of branding and customization is a big reason for its success. When I go take a look at a new project on GitHub, I don’t have to figure out how to navigate a new site’s design, and this makes the GitHub ecosystem as a whole easier to use.

                  1. 3

                    I don’t mean corporate/design branding.

                    I want to use my own name (and be able to move providers without breaking links).

                    1. 1

                      I want to use my own name (and be able to move providers without breaking links).

                      But that will happen anyway, unless your new provider uses the same software as the old one.

                      1. 1

                        Yep - so it has to be oss too.

                  2. 2

                    You can do that with Gitlab (or Gitea if you prefer something lightweight). Only thing is you need to take care of the hosting yourself. But I’m sure there are companies offering a one-click setup, to which you can later point your own domain.

                    1. 2

                      If you host your own gitlab instance, can you fork and submit patches to a project that’s hosted on gitlab,com, as easily/seamlessly as if you were hosted there?

                      Centralization has benefits that self-hosting can’t always provide. If there were some federation which allowed self-hosting to integrate with central and other self-hosting sites, that seems like a new and interesting feature.

                      1. 4

                        Git is already federated with email - it’s specific services like GitHub which are incompatible with git’s federation model (awfully conveniently, I might add). sr.ht is going to be designed to accomodate git’s email features, both for incoming and outgoing communication, so you’ll be able to communicate easily between sr.ht instances (or sr.ht and other services like patchworks or LKML).

                        1. 2

                          As I mention earlier, though, federation by email has been available for a long time and hasn’t been used (by enough people to replace github). The (vast) majority of developers (and other repo watchers) prefer a web UI to an email UI.

                          1. 3

                            I intend to build a web UI which is driven by email underneath.

                        2. 3

                          The gitlab, gitea, and gogs developers are working on this but it’s still very much in the discussion stage at this point. https://github.com/git-federation/gitpub/

                          1. 1

                            Oh, definitely no federation. Didn’t know that federation was what he was looking for.

                            1. 2

                              I don’t know exactly what he was looking for, but It seemed like one of:

                              • hosted, centralized, but with my domain plus some branding, or
                              • self-hosted but with the features of centralization, including community, etc

                              The latter sounds to me like it would need federation.

                          2. 1

                            It’s currently awkward to run multiple domains on most OSS servers which might otherwise be suitable.

                        3. 3

                          hg isn’t really an option right now, though. There’s nowhere to host it. There’s bitbucket, and it’s kind of terrible, and they keep making it worse.

                          If you can’t even host it, people won’t even try it.

                        4. 13

                          I’m afraid you’re not going to find a sympathetic ear in sr.ht. I am deeply fond of git and deeply critical of hg.

                          The GitHug hegemony has nothing to do with its basis on git. If git were the product of GitHub, I might agree, but it’s not. If you really want to break the GitHub hegemony you should know well enough to throw your lot in with the winning tool rather than try to disrupt two things at once.

                          1. 3

                            Do you mind expanding on why you are deeply critical of mercurial?

                            1. 7

                              Perhaps some day I’ll write a blog post going into detail. The short of it is that git is more Unixy, Mercurial does extensibility the wrong way, and C is a better choice than Python (or Rust, I hear they’re working on that).

                              1. 3

                                Git IS more unixy! Using hg feels suspiciously like using a GUI and I can’t figure out why.

                                1. 3

                                  because hg‘s command-line interface was “designed”, whereas git’s command-line interface “evolved” from how it was being used.

                            2. 0

                              The GitHug hegemony has nothing to do with its basis on git.

                              Exactly; it’s the other way around. Git got popular because of github.

                              Git was much worse before github made it popular. It’s bad now and difficult to use now, but it was much worse before 2008. So if you just want to get away from Github, there’s no need to stay particulary enamoured with git either.

                              And whatever criticisms you may have about hg, you have to also consider that it has good ideas (those DSLs above are great). Those ideas are worth spreading, and git for a long time has tried to absorb some of them and hasn’t succeeded.

                          2. 2

                            @SirCpmwn, how did you land on the name/domain sr.ht for this?

                            1. 2

                              I saw it was available years ago and bought it before I knew what I would do with it.

                            2. 2

                              feature request ideas that might be nice (though may also be bad ideas):

                              • Man page or documentation page system side by side with the code, an easy way to get some basic docs that would look something like https://ziglang.org/documentation/master/. A pain point seems to be getting docs hosted for multiple released versions of software.

                              • A nice system for uploading and hosting signed release binaries.

                              • Some sort of triggered checklists for various events. i.e. when a tag is done, a checklist might appear reminding people to upload tarballs and update a demo server.

                              1. 2

                                Hey, thanks for sharing your ideas! Can you direct them to ~sircmpwn/sr.ht-discuss@lists.sr.ht for posterity’s sake? I’ll copy my reply there when you do:

                                Man page or documentation page system side by side with the code, an easy way to get some basic docs that would look something like https://ziglang.org/documentation/master/. A pain point seems to be getting docs hosted for multiple released versions of software.

                                I intend to support this through a combination of continuous integration and static website hosting. At the moment, I compile my Jekyll blog on builds.sr.ht with a job like this: https://builds.sr.ht/job/4713. This rsyncs it to private hosting, but in the future I want to offer a service to sr.ht for hosting static content like this. You could run some offline documentation generator in your build and send up the artifacts. I think this is similar to how Zig’s docs are done today.

                                A nice system for uploading and hosting signed release binaries.

                                Noted, may end up tying this into the stuff I mentioned for doc hosting.

                                Some sort of triggered checklists for various events. i.e. when a tag is done, a checklist might appear reminding people to upload tarballs and update a demo server.

                                This is very WIP, but I’m working on dispatch.sr.ht for this sort of thing. Basically its job is going to be to ingest events like git pushes, emails on mailing lists, etc, and kick off a CI job. From there you can do whatever you want, really. I’m also going to make a simple package that runs in the guest you can use to conveniently script authenticated tasks like sending emails to the mailing list or using the API. Today various projects use the very-early service to tie GitHub projects to builds.sr.ht Travis-style.

                              2. 0

                                Redmine anyone.

                                Trust me. I like this too. But I guess I am a Redmine convert.

                                1. 17

                                  If you want to suggest redmine, that’s ace. It’s good to know about the alternatives - but please back it up with why you think it’s a strong competitor. If you’re supporting it here, you probably have insight worth sharing with us.

                                  1. 1

                                    Well it has a nicer interface I think. Has support for plugins from what I remember and yeah. May as well check out their site. I used it a while ago, so I cannoy remember much.