The one that made me go "oooh!" is this:
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
Logging in via SSH seems useful although that would mean keeping the machine running after a failed build.
For example, Gitlab CI has a local runner but it's not really first class, definitely isn't kept up to date with the real runners. It seems like it's more of a recreation of a job system based off of (an older version of) Gitlab CI configuration files.
Circle CI has a more decent story around this if I remember correctly. But first-class support for local reproduction of CI runs is the kind of thing I'd like to see as table stakes today.
It can be challenging to debug certain things in the live CI system for developers without being able to recreate locally (otherwise you have to bring in the team that manages the CI system to help them debug with you which takes time).
I don't understand why this would be true.
For $dayjob I've been writing end-to-end tests that run via GitHub Actions. Each test starts with a package of the compiled code (built by another GHA workflow), deploys a bunch of cloud resources including a VM, scp's the package to the VM, and ssh's to the VM to install the package and run the test. The package contains multiple services that must be individually configured based on the particular test, and then a test process interacts with these services in a bunch of ways. I think we can agree these are complicated tests; they're not just unit tests you can run in a Docker container and be done with (which we also have, of course).
Now, these tests are written entirely in a shell script. It has been designed from the start that a developer can run the script locally and get exactly the same result as when GHA runs it. The things like auth tokens for the cloud are read as environment variables, so when running as a GHA workflow the env vars are hooked up to repository secrets, but when running locally the developer can just provide their own auth token via env vars to the script. Furthermore, the script cleans up the cloud resources when it finishes, but if the developer wants to investigate the failure they can just comment out the cleanup step from the script.
I'm sure there are third-party GH Actions to create those cloud resources, to scp files to remote targets, and to run commands via ssh against remote targets. But using those actions not only removes the ability to run the tests locally, it also requires learning arbitrary DSLs ("How does this action take parameters? What limitations does it have? How do I process the output of one action to be the parameter of the next? How do I parallelize these two actions that don't need to run in series?") and introduces third-party code that you have to trust with your cloud auth token.
The problem is that we need a ton of logic in the coordinator. For example on how to do matrix builds. For local builds to be perfectly similar we would have to recreate that logic inside the runner. This is hard, not in the least because it are different programming languages.
For someone like me this[0] looks like a good start.
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!
Welp, that puts me off using it entirely sadly. I hate dealing with mailing lists and refuse to contribute to any project that requires dealing with text patches in 2020. Like it or not, the pull request model is simply easier to deal with and is easier for new users to use.
If you prefer to use a web-based workflow, then you can both prepare and review patches on our web UI, and they're automatically sent as emails. You don't actually have to interact with email directly at all.
And, once you're used to it, pretty much everyone who uses email can assure you that it's much easier to use, much more efficient, and much more scalable than pull requests.
I don't really agree with this. Many projects enjoy a vibrant development community on mailing lists today. Cairo suffers from different issues - and ultimately in Cairo's case it doesn't really matter. Cairo has been "done" for years, it's not the end of the world if it doesn't see much activity.
>Do people really want to deal with text patches in 2020?
Yes. You'll find many of them in this very thread. SourceHut is a brand-new service, only around for 2 years in alpha, and in 2020 alone it transacted 37,000 emails. There's obviously demand here.
One thing that can matter a lot if you're trying out the email workflow is making sure you're using a good client. I made one that I recommend as such: https://aerc-mail.org. Other good choices include mutt and alpine.
Can you read those discussions later in a "flat" presentation without scrolling through emails one-by-one?
These are some of the killer features of the PR/MR Github/Gitlab workflows.
To clarify, I'm talking about steps 4-7 here: https://docs.github.com/en/free-pro-team@latest/github/colla...
As well as the "Resolving conversations" section.
Yes, except for the last bit. Unlike GitHub/GitLab you can also respond to several comments at once.
>Can you read those discussions later in a "flat" presentation without scrolling through emails one-by-one?
I don't know what this means.
Person 1
> Chunk of code 1
Comment
> Chunk of code 2
Comment
Person 2
> Chunk of code 1
Comment
> Chunk of code 2
Comment
Chunk of code 1
Person 1
Comment
Person 2
Comment
Chunk of code 2
Person 1
Comment
Person 2
CommentLooking forward to experiencing it in practice someday. Maybe Emacs will finally migrate off Debbugs.
The issue is brought up repeatedly, but there's no real movement right this moment (or for the last several months, really).
There are several proponents of SourceHut thanks to its email-based workflows and (apparently?) LibreJS compatibility. But none are passionate enough to push for it, thus far, and do the work required.
As opposed to, say, advocates of Gitlab (which got effectively banned by a long list of requirements, alas).
Um, what?
Suppose you have 10 developers sending an average of 10 emails a day. That's 100 * 365, or 36 500 emails a year.
That stat doesn't sound very useful. 10 developers isn't demand.
Cairo's fast antialiasing mode had a memory corruption bug that took 5 years after the bug report to be fixed. https://gitlab.freedesktop.org/cairo/cairo/-/issues/44
There are some more options here:
This also only works well if you have: 1) one commit per change, 2) every reviewer has a fully up to date copy of any/all repos being reviewed, 3) a single change only affects a single repo.
The one-commit-per-change (squashed changes) is not always the preference, but it's effectively mandatory since the presentation format for patches only lends itself well to an isolated patch-diff and not a VCS history of changes (ironic since it's intended for the latter). As a great example of this, it's very difficult to compare the differences between the resulting code between two patches submitted to the same thread when I want to confirm a series of corrections to the original submissions were made properly and without side-effect.
Every reviewer having a fully up-to-date copy of the repo the changes are going into works amazingly well for a fully distributed VCS, defining the gatekeeping maintainer's copy as the ultimate source of truth for the "latest". When multiple maintainers for the repo exist, as in most corporate environments and the monorepo organization, this breaks down. The ultimate source of truth for "latest" is now a remotely hosted repository that no one individual gatekeeps. Therefore all maintainers need to constantly duplicate the remote copy and keep it up to date. Either the maintainer is an active developer that's also creating changes constantly and will therefore need to keep two different copies so they can be building and testing their own development changes while keeping a pristine copy purely for review purposes, or they don't usually do a lot of active development themselves and keeping a local copy at all is purely for the purposes of review. In terms of pushing proliferation of copies of the distributed VCS it works, but when more (but not completely) centralized as most corporate environments/users need it's an extra hurdle that impedes the process rather than helping.
For a single change to affect only a single repo requires at the extreme a monorepo layout, or an extremely well modularized design. As noted before, monorepo is very much against the design (few people should need a fully history copy of the entire repo locally with a monorepo, and many maintainers control the same repo) and defining sufficiently modularized breakdown is nigh impossible with larger projects. The Linux project is a great example of this problem, but has a semi-solution that involves having an even larger developer base involved at different levels of a heirarchy, and split repos for "modules" (independently maintained subcomponents or specialty areas) that have to manually cross-related. This is demonstrably problematic even now when a sub-area uses a separate repo and submits wholesale changes to the downstream project, losing almost all of the history and cross-linked-tracking information in so doing. Recognized as a common problem, the community has either gone the monorepo route where all changes go into the single larger repo at the cost of much greater coordination requirements, or the submodule-like route where each sub-part becomes more isolated but may have cross-cutting changes across multiple separate repos. As the repos proliferate in the latter case, individual maintainers often become responsible for a larger number of repos and the other two problems impact them more.
In summary, the mailing list solved a basic problem for a specific narrow use case at a time when technological constraints and solution options were very different than they are now. While the development/maintenance process can still be made to fit its usage, the large scale needs often no longer match, nor do the same technological restrictions apply. GitHub PRs aren't necessarily significantly better, but they do at least move the same concept to a place where an individual user/maintainer can keep their individual source of truth in one place (online), interact with it without needing a full development system/setup present, AND provides options for moving development processes in a new direction. The last has stagnated pretty badly, but throwing it out for a return to a system that has little to no options for modifying the process to meet modern needs seems overly agressive.
How do I make a minor adjustment to a patch as a response to feedback without resending the whole thing? Anything more complicated than git commit && git push to my remote clone is not easier nor more efficient than the status quo.
These are just two off the top of my head. PRs as a code contribution approach can be improved upon, but mailing lists are not better at all for small projects and are only situationally better for bigger ones.
https://lists.sr.ht/~sircmpwn/sr.ht-dev
>How do I make a minor adjustment to a patch as a response to feedback without resending the whole thing? Anything more complicated than git commit && git push to my remote clone is not easier nor more efficient than the status quo.
git commit && git push also re-sends the entire thing, assuming you rebased, and you should very definitely be rebasing.
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 first place.
> git commit && git push also re-sends the entire thing
Which is not what I wanted, since even half-arsed PR implementations like Bitbucket's (let alone better ones like GitLab's) support dealing with direct feedback and changes that respond to them in a single PR.
> assuming you rebased, and you should very definitely be rebasing.
I do, when working on feature branchs. But that's another nonintuitive thing to get people to unlearn and relearn. Which of course, also includes git send-email.
You can already filter by project, though. Here are all the git.sr.ht patches:
https://lists.sr.ht/~sircmpwn/sr.ht-dev/patches?search=prefi...
The feature is hinted at in the placeholder text on the search box.
>support dealing with direct feedback and changes that respond to them in a single PR.
Linking multiple versions of a patch together into one cohesive patchset is another thing which is possible in theory and prioritized for the alpha.
>I do, when working on feature branchs. But that's another nonintuitive thing to get people to unlearn and relearn. Which of course, also includes git send-email.
Both of which we have detailed tutorials for!
You leave me thinking you actually give a shit about not leaving the average person behind and that ease of use is a priority. So if you can eventually couple the simplicity and performance you already have with slight changes to make the UI at least as obvious as GitHub to both programmers and students, then that's a winner. Just subscribed in hopes to seeing that happen.
Github has needed a non-web-app interface since 2007. It's good to see real competition and not just another clone of github's, erm, interesting design choices.
I also want nothing in the critical part for development to be email, so I can completely ignore the whole email client.
Yes I know you can automate filtering them in to folders but that isn't simple to do when you self host email and use it across multiple computers because most filtering is done client side.
I also have one mailing list that seems to have messed up and I'm stuck on the list despite trying to unsubscribe a few times.
Anyway, email has threading, at least. At the very minimum github needs to step up and acknowledge how terrible issues are for communicating.
Git also had a git-request-pull command that prepares a mail with the same information that you can find in a pull request on GitHub even before GitHub existed.
There is no "one true way" to Git and if organization to adapt their workflow to their needs they can have issues both with mailing lists and the centralised forge model.
https://drewdevault.com/2020/09/02/Linux-development-is-prof...
To be clear, sourcehut does occasionally use JavaScript, it’s just very conservative and optional.
This is imho the most important part.
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.
Whether that matters to you or your business is a different story.
If you look at the direction of most popular products that are open-core, you have a spectrum from ElasticSearch (Slightly hobbled, the free x-pack features that you WILL use in production put you at risk of dipping into paid uses and in violation. running Amazon's fork/open distro is strictly better) to Neo4j (completely unusable in a production context without a paid, mega-expensive, cost-of-a-nice-house-per-year license. No clustering, can't be effectively monitored, none of the tuning knobs that you will need as your dataset grows).
Open-core licenses are entirely hostile to the spirit of OSS and just pay it lip service to delude the ignorant.
Also, the simplicity is certainly appreciated.
- The whole premise assumes that you need to make a new account for each project you contribute to, because they're hosted on individual gitea or similar instances. Some are, but let's be honest, the vast majority of projects are currently hosted on a very small set of services (github, gitlab, one or two others), and most developers will already have accounts on them.
(I get that part of the goal is to eliminate dependency on large code hosting services, and I agree with that. But we should do that with federation standards so people can use individual gitea/whatever instances without making accounts on all of them, not by traveling back in time 20 years.)
- He spends a lot of time complaining about silly password requirements. The complaint is valid but not relevant to the comparison.
- The graylisting thing is an own-goal, sorry.
- He complains that forking the repo and creating the PR require context-switching from the cli to the web and back, but there are cli tools that can fork repos and create PRs for you on github, gitlab, etc. to fix that.
- Let's allow that submitting a single patch, starting from outside the project, is faster for the contributor with an email workflow. But that's a tiny part of the process. There's a lot of things that happen after that patch: the project maintainers have to triage it, they have to review it, make comments on specific lines of the diff, or sometimes on line that aren't part of the diff, and then indicate that the submitter should make changes and try again. The submitter then has to make changes and submit it again. The reviewers, at that point, will probably want to see the diff between the first and second revision.
Triage: The github/gitlab UI for this is not great but acceptable. Viewing a mailing list in my email client mixes discussion and patches. I can't mark threads with labels or priorities. I can't assign a particular review to a particular person and have it show up in their todo list.
Review: Sure, you can reply to a patch posted on a list and intersperse comments, but web uis for code review are pretty decent these days. You can easily see much more of the context when required, your comments and replies on specific lines get threaded even across revisions of the code, each comment thread can have an individual "done" indicator, etc. The review as a whole has a global status of whose turn it is to take an action next. All of these seem much harder by email; you end up just using a lot of conventions.
You can use a web-based review tool with email-based patches, of course, but... why bother? If you're doing web-based review, just do the whole workflow there and it'll be a lot simpler and easier to understand.
Resubmit: Resubmitting a patch set by email posts brand new diffs. How do I see the differences between different versions of the patch? Sure, I can rig up a bunch of scripts to do this, but is it integrated with the review tool, etc.?
- What happens when I become a maintainer? I have to sign up for a new mailing list. And that means I have to go in my email client settings, make a new folder, make a new filter rule to direct email from that list into that folder. That's a huge amount of friction that doesn't exist in the web-based workflows.
You can mark emails with labels though depending on your Email client. The onus is on you. SourceHut also supports adding labels to SourceHut tickets through email I believe.
You can assign a review to someone. You literally just CC them on the email.
> And that means I have to go in my email client settings, make a new folder, make a new filter rule to direct email from that list into that folder. That's a huge amount of friction that doesn't exist in the web-based workflows.
If that is a lot of friction for you, then you probably either have a horrible email client, or don't know how to use it.
I used "hub" back in 2013, so it's at least that old. It wasn't official, though I'm not sure why that makes any difference. Searching on google for "gitlab cli clients" shows a bunch, at least some of which have histories dating back to 2013.
> You can mark emails with labels though depending on your Email client. The onus is on you.
But those are local to you and your client. I'm talking about labels that are shared state, that the whole project and the public can see. Those are widely used on github for categorization, triage, communicating the stage of the review, etc. They're undeniably useful to teams. You can put all that information in English text in email bodies, but then everyone has to read a whole thread to understand the state of things, and there's more potential for confusion.
> You can assign a review to someone. You literally just CC them on the email.
Same thing: how do I assign a reviewer so that everyone can quickly and unambiguously see who is assigned to review that PR/patch set? With PR metadata, this is trivial. With mailing lists, it depends on social conventions.
> If that is a lot of friction for you, then you probably either have a horrible email client, or don't know how to use it.
Thank you for insulting my intelligence. I didn't say it's hard, I said that it adds friction.
I'm not claiming that the web-based PR and review UI works for everyone; obvious email works fantastically well for Linux (though I'm not convinced something else couldn't work even better). I do think it works very well for small to medium size projects (which are most projects, after all).
An accurate comparison of the strengths and weaknesses of each model would need to be much more thorough and look at the entire development cycle, for projects of different sizes. I don't agree that that video was anything like that. It seemed like a cheap shot, based on one cherry-picked metric (time to submit an initial patch starting from nothing) that's not particular representative.
2. I'm not sure if your intent was to insult Drew DeVault personally, or to insult the SourceHut project. Drew has given us no reason to doubt his competence, and SourceHut is already accepting payments. Neither sense of the word amateur applies here.
3. That's not what security-by-obscurity means. It would be a bad default, instead, but as Drew has since explained, it's not even that. Unless you explicitly request creation of a public repo, you won't get a public repo.
> 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)