Live data from Hacker News

Considering Sourcehut

postmarketos.org

11–20 of 81 posts

Re: Considering Sourcehut

#11

Quoted post unavailable.

Because many people are afraid of what is not familiar, that's it. It's not hostility, but a rather a case of shying away from reading the docs and changing the way they work. From my experience not everyone is conductive to try and adapt to new ways, and many people do not use git CLI or SSH. They just use GitHub's gh CLI command.

This needlessly dismisses people who have tried both and still prefer not to use the one with more hassle.

Believe it or not, there are people out there who don't care about decentralization and latency-tolerant store-forward networking for their own sake. Getting things done is way more important to them and the user experience of git send-email is simply not as good as the centralized version.

Re: Considering Sourcehut

#13
post #11

Earlier quoted context omitted.

Because many people are afraid of what is not familiar, that's it. It's not hostility, but a rather a case of shying away from reading the docs and changing the way they work. From my experience not everyone is conductive to try and adapt to new ways, and many people do not use git CLI or SSH. They just use GitHub's gh CLI command.

This needlessly dismisses people who have tried both and still prefer not to use the one with more hassle. Believe it or not, there are people out there who don't care about decentralization and latency-tolerant store-forward networking for their own sake. Getting things done is way more important to them and the user experience of git send-email is simply not as good as the centralized version.

People can have preferences, I deeply respect that.

On the other hand, I put my code out there (anywhere), and people are free to decide whether they contribute to it or not.

This is the platform I use, and this what the platform provides. If they want to contribute, and don't prefer the mail flow, they can reach me, and we can discuss it.

This is a two way street. Nobody is forced to contribute to anything, and I have no obligation to use services which people prefer. No?

Re: Considering Sourcehut

#14
I use sourcehut for a few projects, and I love the build system. I don't have extensive experience with build systems, but I've explored a handful. What I love about sourcehut's build system is that for the most part it's just straight up scripts/commands. If I can do it in Linux, then I should be able to get it going without difficulty via sourcehut builds. As a result, there's also not much about it to learn. Most of it uses my existing knowledge of Linux and surrounding tools.

The git-by-email setup is more inconvenient. I haven't found an email setup I'm comfortable with. I also haven't tried a lot, but with a pull request system like github there's not really anything to try.

Overall quite happy with sourcehut for my needs.

Re: Considering Sourcehut

#15

I use sourcehut for a few projects, and I love the build system. I don't have extensive experience with build systems, but I've explored a handful. What I love about sourcehut's build system is that for the most part it's just straight up scripts/commands. If I can do it in Linux, then I should be able to get it going without difficulty via sourcehut builds. As a result, there's also not much about it to learn. Most…

> The git-by-email setup is more inconvenient.

Due to the distributed nature of git, that's not actually required. Any sourcehut project can merge branches that exist in different places on the Internet.

The feedback and reviewing process might be more cumbersome, but accepting code contributions is not impeded in any way.

Re: Considering Sourcehut

#16
post #5

Quoted post unavailable.

Because: - UX is important to the average software developer - UX within popular email clients targeting the task of code review is non-existent - UX within IDEs for code review is better but: (a) send-email integrations are less polished/mature than they could be (largely due to the dominance of PR/MR flows) and (b) IDE code-review UX is still, despite everything, lagging Web UI code review UX TL;DR: open distribute…

> (b) IDE code-review UX is still, despite everything, lagging Web UI code review UX

This can't be overstated. Visual Studio Code seems to be making moves in this direction at least, but then again it's GitHub specific I believe?

Re: Considering Sourcehut

#17

Quoted post unavailable.

> Why are so many of your great contributors so hostile to the only part of the Internet that is still truly decentralized?

> Why do they hate store-and-forward, latency-tolerant networks?

I do like email-based development. And I pay for Sourcehut. But I also understand why others don't like email-based interfaces. And I too sometimes get annoyed by Debian's BTS taking minutes to act on (email-based) changes to bug reports. Minutes where I'm just idly sitting around waiting so as not to have to context switch. I abhor GH and friends, but oh man sometimes an instantaneous interface is important.

Re: Considering Sourcehut

#18

I use sourcehut for a few projects, and I love the build system. I don't have extensive experience with build systems, but I've explored a handful. What I love about sourcehut's build system is that for the most part it's just straight up scripts/commands. If I can do it in Linux, then I should be able to get it going without difficulty via sourcehut builds. As a result, there's also not much about it to learn. Most…

>What I love about sourcehut's build system is that for the most part it's just straight up scripts/commands. If I can do it in Linux, then I should be able to get it going without difficulty via sourcehut builds.

FWIW, it's possible to do it for GitHub etc as well. These CI providers try to get you to use their bespoke "Actions", ie custom DSLs that only work with the one CI provider, but nothing prevents you from ignoring all that and just writing an "exec this shell script" step. It's what I do for all my GitHub repos. I can run the script locally just like the GitHub CI does it in its VMs.

Re: Considering Sourcehut

#19

I use sourcehut for a few projects, and I love the build system. I don't have extensive experience with build systems, but I've explored a handful. What I love about sourcehut's build system is that for the most part it's just straight up scripts/commands. If I can do it in Linux, then I should be able to get it going without difficulty via sourcehut builds. As a result, there's also not much about it to learn. Most…

>What I love about sourcehut's build system is that for the most part it's just straight up scripts/commands. If I can do it in Linux, then I should be able to get it going without difficulty via sourcehut builds. FWIW, it's possible to do it for GitHub etc as well. These CI providers try to get you to use their bespoke "Actions", ie custom DSLs that only work with the one CI provider, but nothing prevents you from i…

It really is the way to do it. Then you are also version-controlling your build-setup and if the cloud or your self-host solution is down at the wrong time you can instantly run an equivalent build locally.

The cloud is really about one thing and one thing only. Vendor lock-in. I don't accept that. And I don't see any sensible reason for it.

Post reply on HN