SourceHut's mailing lists host the development, announcement, and discussion archives for the sr.ht code hosting platform, run by Drew DeVault.
HN commenters cite the public mailing list archives as a good example of web-viewable lists, and discuss self-hosting SourceHut.
> https://lists.sr.ht/~sircmpwn/sr.ht-dev
That's a multi-purpose mailing list, where I had to read for a couple of minutes to assume belongs to the whole project sr.ht instead of a specific repo (I trusted your response to mean this was an actual 1:1 replacement and that I missed it), and I had to go into one of the patches and find a link to an issue in the tracker, and from there I had to go to the main page of that issue's project, and from there I see there's an ad-hoc association between the tracker and the actual repo by a link in the description which I assume you added because you noticed that it's useful to associate issue trackers and repos. And that's just for finding one of the repos that mailing list covers.
In the end, I still have to come up with custom filters to use to get only the patch requests for the specific repo I'm interested in, and assume everybody follows every single non-obvious instruction to the letter to make it all work.
The whole experience feels like a grabbing a bunch of general purpose tools and trying to get them to work for the project's purpose as well as possible, because there is no solution that solves the problem in obvious ways that doesn't require learning and carefully following a bunch of ceremony without failure. Except in this case, there are such solutions, and I'd have to be a sadist to try to get coworkers to learn and follow every single convention to the letter when they have problems just working well with git in the…
This is really exciting! I particularly like the lightness of the web-pages and the non-necessity of javascript. The support for the BSDs in the build system (FreeBSD at the moment, OpenBSD and NetBSD planned[0]) is also nice — as a Linux person I've far too often ignored the other Unixes and POSIX / general Unix compatibility.
I hate being THAT guy, but would you consider trying[1] to re-license the AGPL-3.0 bits to AGPL-3.0-or-later, unless sticking with just v3 was deliberate (in which case fair enough)? My rationale:
i) License-incompatibility is a curse that fragments the copyleft world.
ii) Worrying about AGPL-3.0-only being incompatible with AGPL-4.0, in ten years time, if/when the latter comes out, will be too late, as (hopefully) sr.ht will have had hundreds or thousands of contributors, many uncontactable, by then.
iii) Having AGPL-3.0-or-later instead of just AGPL-3.0 is unlikely to put off any contributors.
iv) (This is subjective and might not hold for you:) I trust the FSF not to do something sufficiently crazy with its next iteration of licenses (if such exist), that I would prefer my code not to be compatible with such licenses.
[0] https://lists.sr.ht/~sircmpwn/sr.ht-announce/%3C20180802214500.GA5332%40homura.localdomain%3E
[1] This obviously also depends on the other contributors, so you might not want to bother with the effort.
That may be, but the fact remains that nVidia is pushing an interface that no other Linux drivers currently support, for reasons that really only benefit them. The Linux kernel team has never been particularly supportive of middleware layers designed to promote common drivers between Linux and other operating systems, and for good reason—it impedes the development of optimized, native Linux drivers.
The only way I see nVidia succeeding here is if they clearly demonstrate that EGLStreams is a technically superior alternative to GBM, not just for their own hardware but in general, and also contribute the changes needed to support EGLStreams for all the other graphics drivers currently using GBM so that applications don't need to deal with both systems. As long as the EGLStreams code path can only be exercised in combination with the proprietary nVidia drivers it will remain a second-class citizen and projects would be well-advised to avoid it. (Drew DeVault goes into more detail[1] in his objection to the inclusion of EGLStreams support in KWin, which I agree with 100%.)
Or they could just acknowledge that this is a Linux driver, not a Windows driver, and implement the standard Linux GBM interfaces like everyone else even if that means less shared code.
[1] https://lists.sr.ht/~sircmpwn/public-inbox/%3C20190220154143.GA31283%40homura.localdomain%3E
SourceHut just feels refreshingly snappy!
Even the homepage has a few links that you can click around, to explore some of the features for yourself: https://sourcehut.org/
"Hosted git repositories": https://git.sr.ht/~sircmpwn/scdoc
"Powerful continuous integration": https://builds.sr.ht/~sircmpwn/job/97412
"Mailing lists & code review tools": https://lists.sr.ht/~sircmpwn/sr.ht-dev/patches/14726
"Focused ticket tracking": https://todo.sr.ht/~sircmpwn/todo.sr.ht
"Markdown- and git-driven wikis": https://man.sr.ht/
I'm not sure what the adoption will be like in the long term (the design might be too minimalist/niche for some), but it's nice to see such variety and focus on usability and meaningful minimalism.
It feels like my install of Gitea and Drone CI, but taken a step further on getting things done and not much more. Probably a pretty stark contrast from what my personal GitLab and GitLab CI instance used to run like (the UI there was great IMO, just slow).
It's nice that we have solutions like that, especially those that can be self-hosted, or just hosted versions for people who don't want to admin their own instances. For now, self-hosted Gitea and Drone CI are good enough for me.
For completeness, here is the reply from one of the KDE developers:
https://lists.sr.ht/~sircmpwn/public-inbox/%3CCAGeFrHA7FyqR24VkOgYO7tfsVEkfhCcvg6DX_jiJSm-y40hdhQ%40mail.gmail.com%3E
(It doesn't appear in the thread because it's been forwarded)
EDIT: and here is a blog post about EGLStreams from another KDE developer (2016):
https://blog.martin-graesslin.com/blog/2016/09/to-eglstream-or-not/
Here is a follow-up blog post from the same author (2017):
https://blog.martin-graesslin.com/blog/2017/10/plasmawayland-and-nvidia-2017-edition/
Here are some (technical) discussions on wayland-devel about EGLStreams (2016): https://lists.freedesktop.org/archives/wayland-devel/2016-March/thread.html#27547
Here are some recent IRC logs from #wayland, also discussing EGLStreams: https://dri.freedesktop.org/~cbrill/dri-log/?channel=wayland&highlight_names=&date=2019-02-21#t-1155
I don't have a reply for most of your comment, but with respect to this part:
>If that is the situation, where does SourceHut stand? The site makes little sense to me. The URL is sourcehut.org, but there is no statement about it being a non-profit, or any discussion about a board that manages it. There is a pricing page, but no contact us page. I don't know where it is based, and I can't find a reference on Crunchbase to get any idea of who owns the company.
I own SourceHut as a sole proprietor, you can reach me at sir@cmpwn.com with private questions or ~sircmpwn/public-inbox@lists.sr.ht with public questions. Archives here:
https://lists.sr.ht/~sircmpwn/public-inbox
The business is operated transparently, here's the latest quarterly financial report:
https://sourcehut.org/blog/2019-10-21-sourcehut-q3-2019-financial-report/