I recently contributed to a project hosted on sr.ht for the first time. It took some getting used to. I can see the potential, but there are some sharp edges.
The email-based workflow could be convenient for some, but speaking for myself, I'd mainly prefer to interact via the web UI. The ability to send updates to patches submitted from the web UI seems to be missing. If I made a mistake or was asked to change something, I had to completely re-submit the patch as a separate email. I couldn't find a way to communicate on mailing lists without using an external email client. Basic things, like needing to hand-wrap my emails at 70-something characters, and remember to remove quoted text from the bottom of emails, is an unfortunate barrier to entry for new contributors. All of these things could be abstracted away via the web UI for those who don't want to use email.
I generally recommend setting up a separate email client for development, and I recommend one I wrote myself for this purpose: https://aerc-mail.org. You don't have to stop using your primary mail client to incorporate a second one into your workflow. Just think of the patches as notification emails in your normal inbox, and then something like aerc as a domain-specific tool. Over time I bet you'll find yourself opening aerc more and thunderbird less, though ;)
We're also working on web-based tools for this workflow, which allow you to create patchsets, respond to feedback, and review them entirely from the web, but these are still WIP. You can submit patchsets and view discussions on the web today, and the rest of the tools are WIP.
Powerful continuous integration
- Runs fully virtualised builds on various Linux distros and BSDs
- Submit ad-hoc jobs without pushing to your repository
- Post-build triggers for email, webhooks, etc
- Log in with SSH after build failures to investigate further
Submitting jobs without pushing and logging in after failed builds are two features that I didn't know I wanted. But now that I see them, I really want them.
I think the most consequential difference is that sourcehut is built on top of existing tools for distributed development with the goal of avoiding lock-in. Instead of replacing the distributed tools traditionally used in FLOSS development (mailing lists, patches) with centralized ones (issue tracker, pull requests), the goal is to provide an interface that makes it easier to use the tools of the distributed model.
The No.1 reason for me is that it makes you use git like it is supposed to be used: Via email and your MUA.
The "pull-request-model" invented by github is an abomination of a workflow. Communities stop scaling because of it (see nixos/nixpkgs) because it does not allow horizontal scaling at all - thousands of "PRs" open, nobody feeling responsible and slowdown overall.
Having a tool that provides only an "overlay" over the workflow git wants to be used with, and that's what sourcehut is, but not a replacement for it (which is what github is), is refreshing and promising!
Not a sourcehut power user myself but for me personally the user experience and aesthetics is way superior. The web client made me think about how tech directly relates to user experience, by having no javascript and minimal style means there's less chance to fuck up, everything is super responsive and simple, there are a lot of features but very well sorted and clear. Also I always prefer softwares that have a lead dev who I respect.
To put it another way, if I want to use the CI, then I can drag in sources from anyone. GitHub, GitLab, raw HTTP, etc. Multiple projects. Then build against not just the usual suspects, but also BSD.
If I want to open up an issue tracker without it being connected to any project, I can go ahead and do that. I can also make it frictionless and have user's without an account go ahead and open up/comment on issues.
And I can self-host each of these "modules" myself, with full documentation on how to do that.
I haven't used them but I think the most important benefit is collaboration (sending pull requests etc...) is done via email and thus is less centralised platfomr than github/gitlab which uses their own mechanisms.
To add to others' comments, another nice detail is that you can simply push to a non-existing repository to create it, rather than having to first create it through the web ui.
I really like the page design, very clear and non-flashy. Looks like time was well spent delivering features and good performance instead of building a "beautiful" page.
Do you really need anything else? To me the design is a feature itself. I don't need to load 1MB of stuff and run a heavy scripting language to display... text (of course that 1MB comes with complementary popups, banners, weird scrolling, autoplying videos, and stuff jumping around for 10s until the page loads entirely).
I, on the other hand, dislike this design. Consider how many devs use Apple products - proprietary products that come in a walled garden, and that in many ways go against developers. A good amount of it comes down to aesthetics. Were Sourcehut to have, say, a "2020 theme" or something, that would help lots of those devs appreciate it more.
Developers are using macOS despite it continually removing features from developers, and are even in some cases defending Apple's decisions. I believe that this design actively harms the adoption of Sourcehut. There are definitely other things Sourcehut should do if they want more of GitHub's and GitLab's marketshare, changing their UI (or adding an alternative UI) is an important part of that process.
We need to get out of this rut of UX/UI design. UX/UI designers’ existence itself is based on generalized condemnation of a group of people: “Engineers are bad at designing and aesthetics.” Every time that’s brought up, I roll my eyes.
The truth is there are some outstanding UX/UI designers and there are some really bad engineers who design terrible unfriendly shit. The reverse is more common from what I’ve seen.
SourceHut is an interesting concept and basically the equivalent of a built-at-home GitHub. It's based on Python (and now Go), runs on Alpine on baremetal in a datacenter in the US. Some of the above aren't just views for SourceHut though, they're more like a way of life. If you'd like to test that join the SourceHut channel on Freenode and ask if anyone has any reference for Dockerfiles or Kubernetes and see what response you get.
SourceHut and other code hosting sites are popping up as a wave of programmers push for decentralization. Some may say that it's in response to youtube-dl, but this has been happening slowly for a while. If SourceHut isn't right for you there's always Codeberg which is essentially a Gitea instance backed by a non-profit in the EU.
Been using sourcehut little over a year now. I'm a fan
Looks real good in dark mode via the standard "dark reader" browser plugin most people use these days, btw. Would love to see them add a native dark mode though. That's my main gripe.
The official response to this ask was "convince the browsers to ship prefers-color-scheme dark", and now that they have, the official answer is "patches welcome". I would definitely be down to add a dark theme if someone put in the work.
I've looked at this with some curiosity over the past year, but it was only this morning that I decided to take a closer look. While I'm a huge fan of GitLab, I think this is really something special. I spent $50 to show some support and I'd like to find other ways I can contribute.
I know Drew is very adamant about using mailing lists instead of pull requests. However, I like the public nature of pull requests and how they archive discussions.
Is there anything that already exists out there to bring that functionality to the email workflow?
Additionally, unlike GitHub, these discussions have been forwarded to all list subscribers, any of whom could trivially turn them into another public archive, independently of sourcehut. Such an archive is also available to list admins in one click for both export and import, in a standard file format. With DKIM and PGP signatures and such, you can even preserve the authenticity of these messages across arbitrary sources.
Any one have personal experiences on self hosting an instance that they wish to share? I keep meaning to look in to it a bit more, but always seem to end up nudging it down the list.
I've been selfhosting it for a while now and the installation wasn't hard when I installed it, and the doc has gotten better since
The hardest part was setting up a working mail server for the mailing lists (but that has nothing to do with sourcehut)
I wish more of the SourceHut stack was written in Go, like Gitea. It would greatly increase performance and simplify deployment. Long-waited NetBSD support in CI[1] would be awesome to be finished too.
More and more of it is being rewritten in Go as part of the API 2.0 project. In any case, SourceHut is already the fastest software forge by objective measures:
> Long-waited NetBSD support in CI would be awesome to be finished too.
As the maintainer of the linked vis project, I can confirm that the provided SSH access to the CI environment is very convenient and saves a lot of time.
I would also like to see the NetBSD support completed. It turns out that up until last week, we missed a #define to compile out of the box[1].
Both are alternative protocols to HTTP. Gopher is an older technology that uses a menu based organization of information. Gemini is newer and seeks to provide an alternative internet with a simpler client implementation.
Judge for yourself if we were out of line. Steve's repository was basically an archive of his Instagram account, hundreds of high-resolution images. This is not what SourceHut is designed for. Mercurial repositories in particular have an outsized impact, because we generate nightly clonebundles from larger repos, and because images are uncompressible this results in a disproportionately large amount of wasted CPU time and disk space.
We updated our approach, in any case, to use the following email template instead:
[+] [-] jniedrauer|5 years ago|reply
The email-based workflow could be convenient for some, but speaking for myself, I'd mainly prefer to interact via the web UI. The ability to send updates to patches submitted from the web UI seems to be missing. If I made a mistake or was asked to change something, I had to completely re-submit the patch as a separate email. I couldn't find a way to communicate on mailing lists without using an external email client. Basic things, like needing to hand-wrap my emails at 70-something characters, and remember to remove quoted text from the bottom of emails, is an unfortunate barrier to entry for new contributors. All of these things could be abstracted away via the web UI for those who don't want to use email.
[+] [-] ddevault|5 years ago|reply
We're also working on web-based tools for this workflow, which allow you to create patchsets, respond to feedback, and review them entirely from the web, but these are still WIP. You can submit patchsets and view discussions on the web today, and the rest of the tools are WIP.
[+] [-] __henil|5 years ago|reply
> Git and Mercurial hosting, mailing lists, bug tracking, continuous integration, and more
> Absolutely no tracking or advertising
> All features work without JavaScript
> 100% free and open source software
For someone who is not familiar with sourcehut what other benefits does it provide over gitlab?
(Don't get me wrong i absolutely like that every feature works without javascript, i am just curious)
[+] [-] wpietri|5 years ago|reply
The one that made me go "oooh!" is this:
Submitting jobs without pushing and logging in after failed builds are two features that I didn't know I wanted. But now that I see them, I really want them.[+] [-] mfsch|5 years ago|reply
[+] [-] musicmatze|5 years ago|reply
The "pull-request-model" invented by github is an abomination of a workflow. Communities stop scaling because of it (see nixos/nixpkgs) because it does not allow horizontal scaling at all - thousands of "PRs" open, nobody feeling responsible and slowdown overall.
Having a tool that provides only an "overlay" over the workflow git wants to be used with, and that's what sourcehut is, but not a replacement for it (which is what github is), is refreshing and promising!
[+] [-] slmjkdbtl|5 years ago|reply
[+] [-] shakna|5 years ago|reply
To put it another way, if I want to use the CI, then I can drag in sources from anyone. GitHub, GitLab, raw HTTP, etc. Multiple projects. Then build against not just the usual suspects, but also BSD.
If I want to open up an issue tracker without it being connected to any project, I can go ahead and do that. I can also make it frictionless and have user's without an account go ahead and open up/comment on issues.
And I can self-host each of these "modules" myself, with full documentation on how to do that.
[+] [-] busterarm|5 years ago|reply
Whether that matters to you or your business is a different story.
[+] [-] njkleiner|5 years ago|reply
Also, the simplicity is certainly appreciated.
[+] [-] rainingcatndogs|5 years ago|reply
[+] [-] nathcd|5 years ago|reply
[+] [-] mahkoh|5 years ago|reply
[+] [-] eatonphil|5 years ago|reply
[+] [-] arch-ninja|5 years ago|reply
[+] [-] hprotagonist|5 years ago|reply
[+] [-] colonwqbang|5 years ago|reply
[+] [-] andrepd|5 years ago|reply
[+] [-] jamescostian|5 years ago|reply
Developers are using macOS despite it continually removing features from developers, and are even in some cases defending Apple's decisions. I believe that this design actively harms the adoption of Sourcehut. There are definitely other things Sourcehut should do if they want more of GitHub's and GitLab's marketshare, changing their UI (or adding an alternative UI) is an important part of that process.
[+] [-] systemvoltage|5 years ago|reply
The truth is there are some outstanding UX/UI designers and there are some really bad engineers who design terrible unfriendly shit. The reverse is more common from what I’ve seen.
[+] [-] kodah|5 years ago|reply
I recently wrote an article for my own code hosting service where I talked a little about SourceHut and what makes it unique:
- SourceHut follows a zero investor approach [1]
- SourceHut's Principal Engineer, Drew Devault, prides himself in simple infrastructure [2]
- Drew believes Mailing List Workflows are the way forward [3]
- SourceHut is designed for accessibility first [4]
[1] https://sourcehut.org/blog/2019-10-23-srht-puts-users-first/
[2] https://sourcehut.org/blog/2020-04-20-prioritizing-simplitit...
[3] https://sourcehut.org/blog/2020-10-29-how-mailing-lists-prev...
[4] https://sourcehut.org/blog/2020-05-27-accessibility-through-...
SourceHut is an interesting concept and basically the equivalent of a built-at-home GitHub. It's based on Python (and now Go), runs on Alpine on baremetal in a datacenter in the US. Some of the above aren't just views for SourceHut though, they're more like a way of life. If you'd like to test that join the SourceHut channel on Freenode and ask if anyone has any reference for Dockerfiles or Kubernetes and see what response you get.
SourceHut and other code hosting sites are popping up as a wave of programmers push for decentralization. Some may say that it's in response to youtube-dl, but this has been happening slowly for a while. If SourceHut isn't right for you there's always Codeberg which is essentially a Gitea instance backed by a non-profit in the EU.
[+] [-] sam0x17|5 years ago|reply
Looks real good in dark mode via the standard "dark reader" browser plugin most people use these days, btw. Would love to see them add a native dark mode though. That's my main gripe.
[+] [-] ddevault|5 years ago|reply
[+] [-] sirodoht|5 years ago|reply
[+] [-] _ix|5 years ago|reply
[+] [-] CivBase|5 years ago|reply
Is there anything that already exists out there to bring that functionality to the email workflow?
[+] [-] ddevault|5 years ago|reply
https://lists.sr.ht/~sircmpwn/sr.ht-dev
https://lists.sr.ht/~sircmpwn/sr.ht-discuss
https://lists.sr.ht/~sircmpwn/sr.ht-announce
https://lists.sr.ht/~sircmpwn/sr.ht-ops
Additionally, unlike GitHub, these discussions have been forwarded to all list subscribers, any of whom could trivially turn them into another public archive, independently of sourcehut. Such an archive is also available to list admins in one click for both export and import, in a standard file format. With DKIM and PGP signatures and such, you can even preserve the authenticity of these messages across arbitrary sources.
[+] [-] yjftsjthsd-h|5 years ago|reply
[+] [-] Rapzid|5 years ago|reply
- Most developers born after 1980
[+] [-] JNRowe|5 years ago|reply
[+] [-] ddevault|5 years ago|reply
Installation instructions are here: https://man.sr.ht/installation.md
There's a patchset in my review queue which will organize, update, and streamline these instructions - might be worth checking back in a week.
[+] [-] ndagestad|5 years ago|reply
[+] [-] peterjsanchez|5 years ago|reply
[+] [-] xvilka|5 years ago|reply
[1] https://git.sr.ht/~sircmpwn/builds.sr.ht/tree/master/images/...
[+] [-] ddevault|5 years ago|reply
https://forgeperf.org
[+] [-] martanne|5 years ago|reply
As the maintainer of the linked vis project, I can confirm that the provided SSH access to the CI environment is very convenient and saves a lot of time.
I would also like to see the NetBSD support completed. It turns out that up until last week, we missed a #define to compile out of the box[1].
[1] https://git.sr.ht/~martanne/vis/commit/01eef9f87b72b0c147367...
[+] [-] setheron|5 years ago|reply
[+] [-] fuball63|5 years ago|reply
https://gemini.circumlunar.space/docs/faq.html
https://en.wikipedia.org/wiki/Gopher_%28protocol%29
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] wirrbel|5 years ago|reply
[+] [-] alisonkisk|5 years ago|reply
[+] [-] mikepurvis|5 years ago|reply
https://drewdevault.com/2018/11/15/sr.ht-general-availabilit...
[+] [-] sirodoht|5 years ago|reply
[+] [-] erk__|5 years ago|reply
[0]: https://sourcehut.org/
[+] [-] tyfytyf|5 years ago|reply
[deleted]
[+] [-] ddevault|5 years ago|reply
https://paste.sr.ht/~sircmpwn/5f6ae83ffc961215cb82f1a98f78a0...
Judge for yourself if we were out of line. Steve's repository was basically an archive of his Instagram account, hundreds of high-resolution images. This is not what SourceHut is designed for. Mercurial repositories in particular have an outsized impact, because we generate nightly clonebundles from larger repos, and because images are uncompressible this results in a disproportionately large amount of wasted CPU time and disk space.
We updated our approach, in any case, to use the following email template instead:
https://paste.sr.ht/~sircmpwn/3d32eb7bbc564170c3d30f041e5e8d...
And we expanded on acceptable use in the documentation:
https://man.sr.ht/hg.sr.ht/#acceptable-resource-usage