The Sourcehut Project Hub
sourcehut.org
sourcehut.org
What I do notice is that the site loads very fast (sub-1s w/ cache disabled via devtools to simulate first visit, and sub-50ms otherwise). That alone deserves big props.
All of our pages are done in 2 requests, or 1 with a warm cache.
Where are the tests being run from?
Is there any way to control for network latency (maybe subtract the ICMP rtt from the tests?)
You might consider comparing it to other Gitea instances like https://try.gitea.io/ (Digital Ocean / USA), https://mirror.git.trinitydesktop.org/ (Czech Republic) or https://gitea.com/ (China), but I guess Codeberg is probably the most representative instance for public use.
https://git.sr.ht/~sircmpwn/forgeperf
The goal here isn't to compare forge software (that would require a completely different approach to level the playing field), but to compare hosted options. The test suite is easily extended with other hosts or pages, and a few people have tested against their own Gitea instance - usually it ranks somewhere just above the middle of the pack.
I can totally imagine making something like Sir Hat (sorry) a part-time project and, in an alternate universe where I am a better coder and more dedicated than I actually am, producing something super solid after a few years. I cannot, however, imagine any universe in which I would produce something that looked as good as this.
I recommended it to the Emacs developers (who are considering moving to some sort of forge-alike site) in part because it seems to fit the FSF's principles, but more because the aesthetics are what Emacs should aspire to: plain text that looks good.
Some tips:
If you're going for a flat look (which you should), don't go the Google direction.
* Make it actually flat; no shadows. Shadows are your enemy. Only use shadows if absolutely necessary, and even then think twice.
* Use solid lines to separate buttons and other colorful objects from the page. This is more accessible than shadows, and looks pretty instead of Google's weird 2014 pseudoskeuomorphism.
Use accessible colors!
* You have no excuse for using a color scheme that isn't accessible; accessible color schemes generally work better for people who aren't design-inclined, anyway.
* There are a bunch of sites you can use to check whether a color scheme is accessible, and there are also a bunch that have a bunch of accessible color schemes already laid out for you.
* Do not believe yourself when trying to justify an inclusion of a pretty color that makes the site less accessible. I know the color is pretty. There are a lot of colors that won't make the site harder to view, though!
Don't break from your design. Ever.
* Nobody likes using an application that has seven different styles of interaction and looks like it's from three different eras depending on the page you're on.
Take some basic design principles and stick to them
I wasn't aware of what an accessible colour scheme is, a bit of searching and clicking led me to the Web Content Accessibility Guidelines guidelines [1]. Now I know to search for something like "WCAG colour scheme" there seem to be many more resources that are a bit less dry.
The tips you've provided are how not to screw up an excellent design. Not how to get an excellent design to begin with.
I'm not really sure what case you would want to use this over GitLab/Gitea which work very well for basically every use case. Especially when you consider that you are driving away potential contributors by using this.
SourceHut is not GitHub/GitLab/Gitea, and you would be ill-advised to treat it as such. I have no intention of building yet another GitHub clone. If you insist on everything having the same workflow, then what utility is there in different tools? Be prepared to challenge your preconceptions when learning how to use SourceHut. The documentation is thorough and has lots of tutorials to help you along the way:
There are no pull requests or merge requests. We use email, which is how Git was designed to be used. This tutorial will get you started:
If you just want a GitHub clone, use a GitHub clone. Don't evaluate SourceHut by that critera.
I know git internals enough to know what a ‘ref’ is, but IMHO it’s a word that’s pretty hard for an average git user to know. I would suggest at least having a tooltip with some text like ‘Git references: branches, tags, etc...’ so that beginners can understand what it‘s used for.
> There are no pull requests or merge requests.
If I remember correctly, I thought that a way to submit patches through a web UI was being developed... Is it still true?
In general this is against our principles. We prefer to teach people how to use powerful tools rather than make less powerful tools that are easier to use. I don't believe that users are not capable of learning new things. In this particular case, this is the first time anyone has commented on "refs" being difficult to understand in the 1.5 years that SourceHut has been around.
>If I remember correctly, I thought that a way to submit patches through a web UI was being developed... Is it still true?
Yeah, this is still true, and somewhat implemented now. The large blue button on the repo summary page can clone the repo to your account, and then be used to interactively prepare a patchset to send to the mailing list. I'm not sure how Polylactic_acid missed it, actually, unless they don't have an account. The UI only works for account holders, though the big button is replaced with instructions on how to contribute by email if you're logged out.
There's a video of the process here:
https://sourcehut.org/blog/2019-10-15-whats-cooking-october-...
IMHO progressive disclosure is important, because if you want something to be widespread, beginners should be able to use SourceHut with little guidance.
> I don't believe that users are not capable of learning new things.
Well, for the users to learn git terminology, one has to start using git — and one of the biggest reasons is to start using git is to clone popular projects or cooperating between different people. If SourceHut is hostile (I’m not saying that it’s currently hostile, but I think it may improve) for people who don’t what a ‘ref’ is, people have to start using GitHub — and the newcomers of SourceHut becomes the very small portion of people who are already an ‘git expert’ and is interested in emailing patches.
If SourceHut wants to make the email patches/other workflows that SourceHut encourages mainstream, I think it’s crucial for git newcomers to be able to use it. It’s a losing game otherwise.
I would prefer to solve these problems by fostering a culture of mentorship, and being responsive to questions. This is what I do on GitHub, too.
I actually just realized that if SourceHut has a site (like git-send-email.io) that explains git that uses the terms ‘ref’ and etc... (so that a git newcomer can build a proper fit mental model), this problem goes away. Not sure if explaining it easily would be possible though.
As someone who was quite familiar with git before using GitHub, GH's use of that term was the only confusing thing. (It is only not a request for others to `pull` your branch to inspect the changes, it's also a request to merge it into some other branch.)
A term like "ref" is at least part of the standard git terminology, and used in important commands that everyone should know like "reflog".
To be fair, when I tried sourcehut the first time around, I did go ‘wtf’ when I saw branches being called refs.
I didn’t end up using it though, so I’m probably not the target market.
I do like the reasoning behind the hub released now though, so maybe I’ll try again.
I agree deeply with the ethos this statement represents. It's hard for me to formulate at the moment what I think this "ethos" is exactly, but I think it's really important. I'll try to explain by example. I think we should favor manpages over Stack Overflow, documentation over Google, composable CLI tools over monolithic IDEs, etc. I think that every engineer on a team should have read the most popular O'Reilly book (or some equivalent) for each of the tools the team works with. Of course, these "rules" are not commandments and we should always strive to be prudent.
Sometimes I'm accused of being cranky for these sorts of opinions, and I guess I might be, but I also see so much time and money wasted because nobody in an organization understands basic tools like SSH or how to use systemd.
The other day there was a developer tool on the front page of hacker news that lets you "run apps in the cloud from the comfort of your own editor". This is in my opinion a sign of the techpocalypse.
Edit: s/UPPERCASE/italics/
these are not really comparable things. I definitely don't think that Stack Overflow should replace man pages, but I still find Stack Overflow valuable. It's value is in finding how someone else solved a problem similar to the one you had, or where you go to ask other developers for help when the your attempt at finding the needed information in the documentation has failed.
It is my observation that, just as much as Stack Overflow and various on-line cheatsheets are replacing man pages (which is unfortunate), man pages are replacing info pages. By that I mean they aren't thorough enough. My eyes opened to that point when I started browsing M-x info in my Emacs, and run across documentation of non-Emacs things. Info pages tend to be more like a book than a short manual. And it's great, since if you're going to be using a tool semi-regularly, going through a book explaining it is a boost in learning time and scope.
And as a more general point: I miss the times when software shipped with book-sized manuals.
> run apps in the cloud from the comfort of your own editor". This is in my opinion a sign of the techpocalypse
I guess it depends on where you compose. The above goes against Unix philosophy, but not necessarily against Emacs philosophy. I.e. I consider Emacs as a 2D interface to composable applications (vs. 1D interface a command line is). So a bit of Elisp that implements a cloud API provides a piece that can be composed with just about every other piece of Elisp in Emacs, yielding a solution that's both composable and convenient :).
You wouldn't hire a carpenter who didn't know how to use a hammer, why do we expect so called "software engineers" to be handheld through using a basic tool like git, which is entirely based on simple structures like a DAG, immutable hashes and pointers?
What do you think of something like Matrix?
I get that some people really like mailing lists, and I am aware of the shortcomings of the pull/merge request model. But I've never really contributed to a project that used mailing lists, and there are some problems I see with mailing list. Perhaps it's just my lack of familiarity with the workflow, but these are some advantages I think the github-style flow has:
- Ability to subscribe to individual pull requests. Many mailing lists are very high volume, and afaik, it isn't possible to subscribe to individual threads. Yes I could subscribe to the list and set up filters, but that is more difficult than subscribing to individual pull requests in github, and getting the filters right could be tricky.
- Ability to search by tags/labels
- Automatic linking between related issues and pull requests (with backreferences)
- The request is itself a git branch, which makes it easy to compare both the current state of the request to master, as well as see incremental changes to the request as individual commits. I'm not sure how to accomplish that in a mailing list.
- Highlighting changes in the diff (source hut actually does this)
I'd be curious to know if proponents of the mailing list flow have anything to accomplish functionality similar to these. Or if there are any tools or tricks they use to make dealing with patch requests in email easier.
Like... that's the program that handles everything that you mentioned.
Yes, one can use specific filters to accomplish subscribing to a particular PR, but that's complex, and when I'm using a generic email client I can't think of how it can not be complex.
Plus, an email program that handles automatic cross referencing of tickets and commits? Where can I find that “better email client”?
Edit: Forgot to mention, even
> It would be nice to write a filter that auto-links tickets and commits depending on the List-Id.
is not possible with sr.ht, due to non-1-1 relationship between mailing list and repository/tracker.
lists.sr.ht already has support for threads and diff highlighting. Example thread: https://lists.sr.ht/~emersion/public-inbox/patches/7077
>Ability to subscribe to individual pull requests
>Automatic linking between related issues and pull requests (with backreferences)
Both are planned
>The request is itself a git branch, which makes it easy to compare both the current state of the request to master, as well as see incremental changes to the request as individual commits. I'm not sure how to accomplish that in a mailing list.
Not planned, but you can pretty trivially do this yourself. Just git checkout -b test-branch before applying the commits locally.
>Ability to search by tags/labels
Already there, kind of. You can search by the patch prefix, which is generally used to indicate the subproject. This is also supported outright on tickets, for which it's arguably a lot more useful.
I guess that works, but it is a few more steps than clicking on a link. And if you are actively working on the project, it means you have to either switch branches or make a new workspace.
> If you insist on everything having the same workflow, then what utility is there in different tools?
I'll admit many if not most git users have only ever tasted the GitHub workflow, but there are also many who have experienced the old school email workflow and the GitHub workflow and legitimately prefer the latter. Two major considerations:
1. A lot of value-add around pull requests, both in terms of organization/filtering and lifecycle features (inline comments/reviews, CI/CD integration, policy enforcement, merging from web interface, etc.). I planned to go into details here and actually wrote quite a few bullet points before realizing I can't do this topic justice without spending a lot of time to produce a huge wall of text, so please excuse me for the lack of details. (Note: not saying CI/CD integration is impossible with the email workflow, but it doesn't seem possible on sr.ht at the moment without manually pushing someone else's patch to a branch of yours -- correct me, and other implementations I have seen are nowhere as streamlined as those provided by GitHub and clones.)
2. Difficulties around git-send-email and git-am. git-send-email.io only covers half of the equation and coverage isn't complete (e.g. In-Reply-To is not covered). Even the incomplete coverage highlights the complexity. Now what about the git-am side of the equation? How do I fish out a patch from my email client, any email client? How do I figure out which commit to apply the patch on top? Then there's the branching and git-am dance. Maybe it could be streamlined if you use some sort of hacker's mail client with ninja plugins, but you'll have a hard time convincing most people to give up their preferred mail client just because it's not git-friendly. The PR workflow, on the other hand, stays within the boundaries of push/fetch/pull/checkout, the basic operations required for working with any git remote and core competency of any git client (if you choose to use one); no ninja mail client required. hub(1) makes it even easier.
I don't think "how Git was designed to be used" is a strong defense, Linus isn't almighty and what he originally designed could be improved.
I can understand not being a GitHub clone, but when flexibility is a stated goal (I'm sort of reading between the lines, correct me if I'm wrong) maybe it doesn't hurt to support multiple workflows (a lot of work of course). Rejecting a popular and arguably superior (for many if not most git users) workflow means leaving a lot of potential users on the table, which is in itself okay depending on your goal.
>CI/CD integration
>merging from web interface
All of this is possible and planned for or already working on SourceHut. Remember, SourceHut is an alpha - don't write it off just yet because it's not entirely complete.
>Difficulties around git-send-email and git-am. git-send-email.io only covers half of the equation and coverage isn't complete
I intend to follow-up with git-am.io at some point, for what it's worth. And I disagree that it's incomplete: it just encourages a workflow which doesn't use In-Reply-To. It covers follow-up patches without it.
>you'll have a hard time convincing most people to give up their preferred mail client just because it's not git-friendly
My response to this is (1) you can use multiple email clients for different reasons, you don't need to give up your current one; and (2) you don't need a special email client to apply patches from lists.sr.ht, every patchset page has a little CLI command you can copy+run to fetch the patch with curl and feed it to git am.
>Rejecting a popular and arguably superior (for many if not most git users) workflow means leaving a lot of potential users on the table
Popular, yes. Superior, definitely not. But leaving that aside: I am okay with leaving potential users on the table. I'm not maximizing the possible userbase of SourceHut. I'm building a platform that embodies my development principles, for people who find those principles worthwhile.
Anyway, it seems to me that once you have all these planned features, the workflow would inch towards the Phabricator workflow, and to a lesser extent the GitHub workflow. The only major differentiator would be that you use emails to send in patches instead of using a branch. The actual code review activity would center around the web interface instead of the mailing list. That would mean (if my interpretations are correct) we disagree to a much smaller extent than I thought, but that would also mean your workflow is actually pretty different from “how git was designed to be used”, which I interpret as the mailing list-centric workflow of lkml (as I understand it; I’m not involved) and other old school projects I have participated in.
Re mail clients:
> (1) you can use multiple email clients for different reasons, you don't need to give up your current one;
It’s possible, but not pleasant. Each client needs to be configured so that mail intended for the other doesn’t clutter it up (not only inbox, but also search, archive, etc.). Usually people already use two or more mail clients to begin with (pc, mobile), so, more configurations.
> (2) you don't need a special email client to apply patches from lists.sr.ht, every patchset page has a little CLI command you can copy+run to fetch the patch with curl and feed it to git am.
Yeah I’m aware of this, but this just brings back the point that you’re using emails but then not really using emails...
_I_ like using emails. But the point of tools like that are so that people who don't like using emails can use other tools instead, and seamlessly collaborate with people who prefer to use emails.
However, I don't like how they treat users, potential contributors, etc.
Like, I started using sway full time, posted a question, started looking at the source code to fix it myself, and then just ended up fixing it for my fork and never pushing it upstream because the main thing I learned through my questions was that my free time is to valuable to deal with them.
Maybe 30 years ago the badge of being able to contribute to open source even though the maintainers are "super tough" meant something. But it's 2020: I want to do things in my free time that make me happy, I want to learn something while contributing to open source, and ideally learn from those who know more than me. So I'd rather just continue contributing to Rust, where everybody is super nice, those who know more teach and mentor those who know less, and in general the community is super open and reflective (e.g. the attitude is not "how come you didn't know this" but rather "which mistake did _we_ make that led you here without learning this along the way").
To me sourcehut is just a fence that keeps the kind of maintainers I don't like at the other side of the github fence.
This attitude is super harmful. Drew is just one person, and they can only do so much, and that does reflect on Sway, which is why I ended up switching back to i3.
What are you talking about? The mailing lists are super friendly.
The interaction was of the form: "I'm having this problem, I've looked at this, what would be the best way for me to improve this". Reply from Drew "No [issue closed]".
Then using sway, I ran into a lot of problems, and many of them were already reported, but closed issues, which closed with a similar exchange.
At some point, every time I had a sway problem, I would search for my issue on Github with the closed filter first. Finding those issues, with no rationale, workarounds, path forward, discussion of any kind....
Yeah, I just stopped using sway a while after and went back to i3. It at least worked, so I never had to interact with their community.
It's worth keeping in mind that maintainers see a lot more issues than you do. It's likely that I've heard and declined your feature a dozen times already, or that it's part of a broader class of problems which has been heard a hundred times. Sometimes, it tests my patience. And sometimes we do just have to say "no" - not every feature or change is desirable, and if we said "yes" to everything, then sway would quickly become a Cronenbergian mess.
https://github.com/swaywm/sway/issues/1005#issuecomment-3315...
where the comment that closes the issue just says "we'll never implement this, issue closed".
I sympathize with you in that, if you had little time and other things to attend to, then just closing an issue is an instant reward of having something less to do.
But I think it would have been better to, first, don't do anything about that issue if you didn't had the time to do it properly (even if you were the one that filled the issue!), which would have been to write down the rationale why you think that feature is not worth its tradeoffs, and also, to have let other users speak up their mind, and see what others think, before making a decision.
For me, that difference in "project culture" is the difference between an open source project that's worth contributing to, and one that is not.
I've grown a couple of very large open source projects, and some of them I look at once a year, and they keep growing with dozens of PRs per week or day! The main reason I am able to just move on to other things is because I've grown and mentor the new maintainers and leaders of these projects , and I know they both carefully listen to the projects users, and are able to grow new contributors, just like I did.
However... I disagree with your suggestions about how to go about this better. You're still coming from a place where all paths lead to the implementation and inclusion of the feature. We will say "no" sometimes, and there's no amount of discussion which is going to change that. We're volunteers with a limited amount of time, why should we lead everyone on by entertaining a fruitless discussion in on a feature for which we have no interest in supporting?
There's a lot of discussion you don't see, too. Discussion on the IRC channel, private discussions between maintainers, snippets here and there on patch reviews and other issues... just because you didn't get your say, doesn't mean that the issue wasn't sufficiently discussed. At some point I just don't want to discuss it any more. I could redirect you to /dev/null and let you say your fill, but I don't think that's fair to you, either. You can't always get what you want, and if I don't always give you what you want, that doesn't make me a bad maintainer IMO.
Not really. Ideally, I'd have read a comment saying: "We discussed this on IRC, and for this and that reason, we decided that this is probably never going to be worth doing. If you have any new information or argument that was not considered above, please do raise it with us, but we are closing this issue for now."
> There's a lot of discussion you don't see, too. Discussion on the IRC channel, private discussions between maintainers, snippets here and there on patch reviews and other issues... just because you didn't get your say, doesn't mean that the issue wasn't sufficiently discussed.
If your discussions don't happen in the open, how open is your open source project really?
You can discuss things on IRC, or whatsapp, or wherever you want, but if a synchronous and/or private communication channel is used to decide on technical issues that impact the project, then you are essentially excluding everyone that doesn't live in your same time-zone, wasn't there on IRC at that time, can't search those IRC logs, wasn't invited in the room, etc. from impacting your project.
That's just not open enough for me, so I don't contribute to projects that work like that.
Rust or th linux kernel discuss everything in the open, so that everyone can see it and participate, whenever they have time to, and make their case. Whether that's a mailing list, a forum, or a github issue doesn't matter.
But closing an issue with "no" isn't very helpful for all those users that weren't in the room where that was decided, and they will all wonder "why".
> that doesn't make me a bad maintainer IMO.
There are dozens of different ways of maintaining open source projects. Just because sway's way doesn't fit me doesn't mean it's bad. It just means that it doesn't fit me. If you'd like to change something so that it fits people like me, the above hopefully explains what the issues for me were. But I don't expect you to do that, and you don't have to do that, and its perfectly fine for you to disagree and don't want to do that.
We're human beings, and we acknowledge that. I don't go out of my way to try and build a community which avoids that fact. Treat us like human beings, people with feelings and knowledge and a limited amount of time. You didn't pay for it, so you're not entitled to support, features, or yes, even explanations of why decisions were made. It's a collaborative effort, run by volunteers, who can stop volunteering whenever they want. Some users get burned by this, but contributors don't, and contributors are more important than users.
Sway is not some abstract concept of a project - it's made out of people.
I know this doesn't directly address many of your comments, but I feel that it hits on a deeper and more important difference in our beliefs. User entitlement is a huge problem in open source, and it burns out maintainers faster than anything else. I don't stand for it.
No, but having discussions somewhere completely unlinked to your open source repository without a searchable archive and no way to link to discussions does.
Hell, even gitter, which is a pretty clumsy tool lets you link directly to discussion, e.g. https://gitter.im/SublimeLSP/Lobby?at=5dce95d835889012b111a0... (although the fact that this project immediately moved to discord, a less open discussion tool without easy searching isn't amazing).
Do you prefer having to answer the same questions over and over in IRC rather than link to the discussion from a single authoritative issue?
For context: I'm 27 and in the last 10 years, I've used IRC maybe twice. To me, and many others, IRC is an opaque, closed, system. I have absolutely no idea how I would start to search your IRC channel. Hell, I thought IRC logs were only for conversations you were present for. If you can't just give somebody a link to a conversation (which you can in Slack, Gitter, Discord, Teams, mailing lists, Jira, bug trackers, etc) then I'm not sure it counts as open.
> so you're not entitled to support, features, or yes, even explanations of why decisions were made
I was initially going to respond by saying "then you shouldn't ask for contributions". However, the sway repo is actually much better than most and the CONTRIBUTING.md makes it pretty clear you should discuss things with the maintainers first.
Perhaps I'll update my projects with clearer guidance as to whether I'm interested in contributions...
https://github.com/swaywm/sway#sway
> Join the IRC channel (#sway on irc.freenode.net).
This is a clickable link.
>without a searchable archive and no way to link to discussions does
This misrepresents how IRC is supposed to work. You're not supposed to catch up on what you missed. You're supposed to have the conversation there. It's like chatting at the watercooler, not writing into stone.
If you're "searching" the logs as part of your normal IRC routine, you're using IRC incorrectly.
>> so you're not entitled to support, features, or yes, even explanations of why decisions were made
>I was initially going to respond by saying "then you shouldn't ask for contributions".
You're not entitled to it, but you might receive it anyway. And the only one of these which relates directly to contributions is explanations - withholding features and support, in fact, leads to more contributions. I have written about this on my blog on several occasions if you want to learn more about this approach.
I fully agree, nobody wants to search IRC logs for technical information about a project.
If the only documentation about a technical decision in an open source project is an IRC discussion, then that project is just doing open source wrong. Those logs are at best hard to search for, and more often than not, non-existent.
When we have "online" meetings (IRC / Discord / Zulip / Matrix / Zoom / ...) to discuss technical issues in our open source projects, we always publish a full summary of the meetings so that everyone who wasn't there can read them and follow the rationale, or raise issues with it.
IRC isn't the problem, the problem is synchrnonous communication channels in general (IRC, whatsapp, telephone, Matrix, ....). If somebody is not available when the discussion is ongoing, they can't participate. That does make your communication channel much less open than, e.g., a mailing list, where somebody from a different timezone can read the discussion 8 hours later and participate in it.
> User entitlement is a huge problem in open source, and it burns out maintainers faster than anything else. I don't stand for it.
What burns maintainers is having too much to do, and the root cause of that is failing to grow other maintainers to help you with your projects, which is impossible to do if you act as a burned maintainer, because open source is something most people do on their free time for fun, and stressed / burned / overworked maintainers aren't fun to deal with.
Sustainable projects have a high-ratio of contributors relative to users. When this ratio is high, it doesn't matter that some users act entitled, because there are enough maintainers to deal with that load. If you have a lot of users, but a relatively small contributor base, that's when things become problematic.
Attracting contributors is probably the hardest part of open source, and like it or not, every project is competing against all other projects for contributors. Projects that are super nice to every user that interacts with them, no matter how "wrong"/"entitled" the user is, or tired its maintainers are, attract the most contributors, because people like working there.
Being tired while dealing with an entitled user and trying to be super nice with them is super tough, but all other alternatives I know are much worse.
and I'm sorry but a project being 'open source' doesn't mean that everyone can or should contribute, not all contributions are good or helpful and if you have a certain standard in mind for your software you have to filter contributions.
- an open source project which you advertise as collaborative open source
- a personal vision for what you want in your project
- and hence, a secret list of requests you will turn down
Then frequently people might spend 10, 20, 30, 60 minutes trying to do something with your project then writing up an issue. You then immediately shoot it down, because it doesn't match your vision, and that person gets burned.
If you have MIT license and no guidance on contribution, that's user error. But if your project has a PR workflow or has that "Imposter syndrome" line about contributions, well, maybe it's partly your fault.
I'm not saying all open source projects should have guidance. But perhaps all projects with a CONTRIBUTING.md and ISSUE_TEMPLATE.md really should have a clear list of features they will outright reject.
So if someone sends you a contribution that isn't good enough, you reject them with a "no", and that's it?
Sure, you can do that. A different project might expend some time teaching that contributor and being nice to them, until their PR can be merged. And then the contributor submits another one that's better, and then another one, and then before you realize it you have another full time maintainer that you can trust.
So when you say that if a contribution isn't good enough you reject it I say "Thank you", because that person will move on to a different open source project, which might be one of mine, and I'll be getting another contributor instead.
You might not think that the work required to attract a new full-time contributor is worth it. To me it is.
I will say, having observed his interactions in a few places, he rubs me the wrong way sometimes, even though it seems his heart is in the right place. I get it, totally guilty of it myself with strongly held views.
Don't mean this as a criticism but rather as a friendly suggestion if Drew is reading, but there are a lot of situations where backing down or just a softer approach is in order, especially now that he's running a business. There are a lot of us that are interested in what he's doing, but hesitant about using his services because it isn't obvious when the it is my way or the highway approach is going to come out.
I do want to point that millitant/obnoxious/ahole is a very subjective judgement. Personally, I've read many of (what's considered) Linus' worst responses, and I did not find them a problem - he is not gentle, and he occasionally uses expletives, but he is factual, and drives the point through in places gentler people waste ten times as much effort, by themselves (and everyone else) to get the same result - and the result IS good.
I, for one, much prefer to be told "this is sh*t, you need to redo this" (assuming, of course, that's a good summary) than going around and around in endless deliberations about specific details.
I was with you for a while, but this goes way too far. You had a bad experience with Drew on Sway, and because Drew is responsible for Sourcehut you project this on any project using Sourcehut as its platform?
I've interacted with ~15 projects on Sourcehut, and all of them are by the same team of people maintaining Sway.
I'm not projecting to all sourcehut projects, just recollecting the experience of all sourcehut projects I've ever interacted with.
Q: does this mean pricing is no longer optional?
And, thank you for the kind words :)
I realize we can all make optional payments but I’d love for you have committed reoccurring revenue you can count on.
(I say this as a huge admirer of what’s you’re working on and accomplished)
https://sourcehut.org/blog/2020-04-13-sourcehut-q1-2020-fina...
Note that I have secondary income sources, and we also make some money from lending our staff out as part-time consultants. It's not important to me to maximize the earning potential of SourceHut. The mission is to make the free and open source ecosystem better, not to make our own pockets richer.
I'll be just as real with you that I'm not going to be the one to maintain it. It's in the best interest in the platform's broader adoption I make my plea. Because people like me will just flounder on the rocks of the GitHubs of the world. And that's not a future either of us really want.
And it's not packed into a single opaque block: You can specify an image to derive your image from and Docker will overlay-mount your image on top of the base image, avoiding the need to store multiple copies of a base image.
Besides, none of this addresses the laundry list of reasons why running the distributions that package your stuff is unfeasible: a server administrator with a Synology NAS, an enterprise lackey with a limited environment, or one working with any of the containers-only enterprise distributions.
Guix System (another really cool FOSS thing) and sr.ht are beautiful projects from the outside but they are hampered by their inflexibility, adherence to dogma, and resistance to critique. I once wanted to play with Guix System's new `deploy` command on a DO droplet and nobody really wanted to consider that their newfangled command was entirely bungled. You can see this kind of treatment to potential contributors echoed in examples throughout this post's comments. It is endemic to FOSS communities. And it sucks.
Ideals are only realized in compromise. There is no example in history of anything else.
However, there is no Docker turn-key installer, and no plans to make one. I elaborated on this here:
https://news.ycombinator.com/item?id=23037232
But, I've also long acknowledged that if someone else wanted to make a set of third-party Docker images, it would be feasible, and I wouldn't be bothered by it (so long as you didn't ask me to support it).
I like the minimalist approach of many aspects of your work. And the whole website using no JavaScript is also very nice to see.
Have you thought about adding some opt-in JavaScript to enhance the user experience?
How is the self-host story for sourcehut (paid or gratis)?
Is there a turn-key variant with turn-key upgrades a la gitlab omnibus installer?
https://man.sr.ht/installation.md
Most people get this done in an hour or two, sometimes with the help of #sr.ht on irc.freenode.net. It's also often made easier by the fact that you can skip any services you don't need, like paste hosting or wikis. By making you go through the steps and set it up, it makes sure to leave you with an understanding of the pieces and how they fit together, so you're better equipped to deal with it if/when it breaks and to adapt it to your particular circumstances. After you set it up, upgrades are usually pretty painless, you just run `apk upgrade` and it takes care of the rest. In general, I think this approach makes a lot more sense than the turn-key Dockerized approach.
I'm not sure I'm a fan of many approaches I've seen (gitlab omnibus is not a docker install, BTW).
You appear to be supporting alpine Linux - and also Debian derived systems - via packackes?
Packages, obviously, is a nice way to install software... If I wanted an appliance - I should set up an alpine vm, install source-hut components I like, point it at a managed postgres instance and a smart mail host - and assume I'll only ever need to do rolling updates via apk - and distro upgrades via alpine?
Is running on Debian likely to be as smooth?
>Packages, obviously, is a nice way to install software... If I wanted an appliance - I should set up an alpine vm, install source-hut components I like, point it at a managed postgres instance and a smart mail host - and assume I'll only ever need to do rolling updates via apk - and distro upgrades via alpine?
Yeah, that's about right. Upgrades are done just by running your normal package manager updates.
>Is running on Debian likely to be as smooth?
The Debian repository is community-maintained, but the maintainer does a good job and a few people have reported sucess using his packages. We also set it up so that upstream releases automatically update the Debian repo. You'll have to depend on him for support, though, not me - his nick is dlax and he hangs out in #sr.ht on irc.freenode.net; and his email is given on the package page. He's a helpful fellow.
Alpine Linux is indeed the officially supported platform, though, and I highly recommend it. I wouldn't dream of running a different system in production, Alpine is simple and reliable and it's easy to fit the whole thing into your head.
> If you remember where you found that link, let me know, so I can update it.
I belive it was the "100% free and open source" link in this very post:
https://sourcehut.org/blog/2020-04-30-the-sourcehut-hub-is-l...
Which goes to: https://git.sr.ht/~sircmpwn/?search=sr.ht
Which does indeed link the repos - which is good - but from a mindset of "how do I self-host?" maybe a bit bare bones.
Looks like if one follows any of the repo links - the install info is at the bottom. May be an artifact of me being on my phone.
As I said, I didn't look very hard.
I really appreciate the no-nonsense/no hype vibe - but at the same time, I really do want a "here's a sane way to get up and running" front and center.
Now, obviously there's a hosted offering - but at my current company we have a few projects that we feel more comfortable self-hosting due to the nature of some of our customers. For some, we avoid third parties, where we can.
And if you're just looking for Git hosting, here is the install doc: https://man.sr.ht/git.sr.ht/installation.md
https://sr.ht/~sircmpwn/sourcehut
In a nice new project hub UI ;)
But both for managers managing many top level projects, and for developers that are part of those (gitlab/yellow, gitlab/pink...)-gitlab falls down a bit on keeping things organized - it's hard to see if issues in yellow is keeping someone busy and so leaving issues hanging in pink.
We have the Analytics feature designed for that [1]. Please be aware of the distinction between Group-level and Project-level analytics described there.
If you have any feedback on how we can improve this feature, or if you have other ideas, please open an issue [2] and share as many details and examples as possible. We'd love to look into it!
Ideally with a filter on which projects to show.
This works for hierarchical structures today, but not across them. (I'm not sure the current data model is easy to bend into this, so it's understandable - it's just one of the few things we've seen that would let us to more of the project mgmnt in gitlab directly).
The Project Hub looks like an excellent way to tie together all the separate Sourcehut services to better compete with other "complete" VCS-based collaboration suites like GitHub and GitLab. In the future, it would be really cool to expose an API to allow adding "custom" services that aren't part of Sourcehut.
It's good to see Sourcehut focusing on project discovery, since this is the area where GitHub excels at the most. When I search for a small CLI/TUI utility, I often run these filters:
- filter out weblangs, frontend-oriented languages, and languages with heavy runtimes (JS, TypeScript, CoffeeScript, Vue, CSS, HTML, Dart, Purescript, Livescript, Elm, Swift, JVM languages, .NET languages, Vala, QML, etc.). I have several shortcuts for many combinations of languages so I don't have to type them out every time.
- filter repos below a certain size (a repo above 10mb is probably full of bloat).
- If applicable, filter out repos whose last commit was before a certain date.
- If applicable, filter by topic
- If it concerns a recent technology, I can filter repositories created after a certain date.
- If I want to try a smaller project that isn't cursed with mainstream success, I filter repositories below a certain number of stars.
For instance, if I feel like my MPD setup is missing something, I might search:
mpd stars:<150 pushed:>2019-01-01 size:<8000 -language:purescript -language:livescript -language:vue -language:javascript -language:typescript -language:coffeescript -language:elm -language:dart -language:java -language:scala -language:kotlin -language:clojure -language:groovy -language:php -language:objective-c -language:objective-c++ -language:swift -language:css -language:HTML -language:haxe -language:csharp -language:fsharp -language:"jupyter notebook" -language:powershell -language:cuda -language:assembly -language:tex -language:batchfile -language:erlang -language:elixir -language:emacs -language:vim -language:plpgsq -language:julia -language:xslt -language:systemverilog -language:verilog -language:hcl -language:tsql -language:jsonnnet -language:gdscript -language:r -language:smarty -language:freemarker -language:nix -language:saltstack -language:"visual basic" -language:"visual basic .net" -language:plsql -language:"rich text format" -language:dockerfile -language:vala -language:QML -language:actionscript -language:matlab -language:alloy -language:cobol -language:graphql -language:m4 -language:qmake -language:fish -language:opencl -language:json -language:rmarkdown -language:xml -language:markdown -language:applescript -language:puppet
It would be great to have a FOSS implementation of an advanced project search utility that isn't limited to (or even part of) any particular hosting provider. Maybe ActivityPub could help facilitate connecting and indexing project metadata from different hosting providers.
[0]: https://github.com/search?o=desc&q=mpd+stars%3A%3C150+pushed...
Personally, I trust fossil-scm for my side projects. Albeit based on a completely different design philosophy, I recommend to check it out for everyone eager to look outside the box.
Am I blind, or is there no link to https://sr.ht/projects from the main sr.ht or sourcehut.org pages? What is the expected path of discovery?