A new free-software forge: sr.ht

By Jake Edge

January 8, 2019

Many projects have adopted the "GitHub style" of development over the last few years, though, of course, there are some high-profileexceptions that still use patches and mailing lists. Many projects are leery of putting all of their project metadata into a proprietary service, with limited means of usefully retrieving it should that be necessary, which is why GitLab (which is at least "open core") has been gaining some traction . A recently announced effort looks to kind of bridge the gap; Drew DeVault's sr.ht (" the hacker's forge ") combines elements of both styles of development in a " 100% free and open source software forge ". It looks to be an ambitious project, but it may also suffer from a lack of "social network" effects, which is part of what sustains GitHub as the forge of choice today, it seems.

The announcement blog post is replete with superlatives about sr.ht, which is " pronounced 'sir hat', or any other way you want ", but it is a bit unclear whether the project quite lives up to all of that. It combines many of the features seen at sites like GitHub and GitLab—Git hosting, bug tracking, continuous integration (CI), mailing list management, wikis—but does so in a way that " embraces and improves upon the email-based workflow favored by git itself, along with many of the more hacker-oriented projects around the net ". The intent is that each of the separate services integrate well with both sr.ht and with the external ecosystem so that projects can use it piecemeal.

There are two sides to the sr.ht coin at this point; interested users can either host their own instance or use the hosted version. For now, the hosted version is free to use, since it is still "alpha", but eventually one will need to sign up for a plan, which range from $2 to $10 per month, to stay on the hosted service. There are instructions for getting sr.ht to run on other servers; it uses nginx, PostgreSQL, Redis, and Python 3 along with a mail server and a cron daemon.

While, overall, the documentation is rather terse and a bit scattered, it is not difficult to get started using the service by following the tutorial . Logging in allows one to create a Git repository; adding an SSH public key to the account then allows pushing an existing repository up to the system. From there, it can be browsed, as shown in the core sr.ht repository , cloned by others, and so on.

As mentioned, sr.ht has not taken the approach of being yet another GitHub clone. Instead, it is geared toward a mailing-list-centric approach, possibly using the sr.ht mailing list component . The sr.ht-dev mailing list (seen at right) provides an example of the user interface for that component. Unlike some other forges or mailing-list replacements, it is not JavaScript-heavy—in fact, sr.ht uses no JavaScript at all, so pages are small (less than 10KB on average) and load quickly.

There is a guide to the preferred development and collaboration style for sr.ht. It is based around git send-email to a mailing list with copies to potential reviewers, much like Linux kernel development is done. Instead of forking a repository on the server, as is done for GitHub and others, a local clone is made, changes are made and committed, then posted for review. Once a patch is ready for merging, maintainers can apply it using git am . As can be seen, this is much different than the web-centric "pull request" model used by GitHub and others.

Wikis for sr.ht can be created using the man component . Wikis are simply a Git repository of Markdown files that get converted to HTML and served when they are visited. In addition, any sr.ht Git repository can have a top-level README.md , which will be shown when the repository is browsed and could provide a link to a project-specific wiki.

The build and CI component, builds.sr.ht , is what DeVault calls " the flagship product from sr.ht ". His announcement notes that he has been working with both Linux and non-Linux (e.g. BSD, Hurd) distributions to have them start using it because " it's the only platform which can scale to the automation needs of an entire Linux distribution ". He also says that smaller users are switching away from Travis CI and Jenkins to builds.sr.ht.

On builds.sr.ht, simple YAML-based build manifests , similar to those you see on other platforms, are used to describe your builds. You can submit these through the web, the API, or various integrations. Within seconds, a virtual machine is booted with KVM, your build environment is sent to it, and your scripts start running. A diverse set of base images are supported on a variety of architectures, soon to include the first hardware-backed RISC-V cycles available to the general public. builds.sr.ht is used to automate everything from the deployment of this Jekyll-based blog, testing GitHub pull requests for sway , building and testing packages for postmarketOS , and deploying complex applications like builds.sr.ht itself. Our base images build, test, and deploy themselves every day.

The build manifests specify more than just how to build the project, "test" tasks can be specified as well. The manifests also specify the platform (e.g. Alpine Linux, FreeBSD) that should be used for the build and test tasks. Build manifests can be placed in particular locations ( .build.yml , .builds/*.yml ) in a Git repository in order to run them automatically when new code is pushed to the repository. More information about builds.sr.ht can be found in the tutorial , manual , and API reference .

There is also a bug/issue tracking component called "todo". Its user manual is particularly brief as of this writing (" TODO: write these docs "). There are other places one will run into missing documentation pages, perhaps most critically for the code review page that is referred to in the lists.sr.ht documentation for those new to mailing lists. One would guess those holes will be filled in before too long.

The project is written in Python 3 and licensed under the Affero GPLv3 . As noted, it is an ambitious project, but one has to wonder whether the mailing-list-centric workflow will survive long term. The instructions on how to set up mail clients and descriptions of proper mailing-list etiquette may not sit well with newer developers. Email is painful to set up and use any more—many are finding alternatives far more attractive.

Ultimately, what a project like sr.ht needs in order to fill out its feature base, grow, and thrive is new projects. There is an existing stable of projects that are run in a way that is compatible with sr.ht, but not very many new projects are going that route—for good or ill. In addition, the social effects of GitHub (and, to a lesser extent, GitLab, at least in the free-software world) are a major piece of what makes that model so successful; it is hard to see sr.ht replicating that to any significant degree. It is an interesting project, though, and one that deserves well-wishes; for compatible projects looking for a home, it is certainly worth a look.

to post comments)