Simon Ser @emersion@octodon.social

You can now attach files (binaries, PGP signatures, etc) to annotated tags on git.sr.ht repositories 🎉

All (male) SourceHut employees will be required to wear skirts

wlroots 0.10.0 has been released:

https://github.com/swaywm/wlroots/releases/tag/0.10.0

sway 1.4 has been released:

https://github.com/swaywm/sway/releases/tag/1.4

https://drewdevault.com/2020/01/21/Stress-and-happiness.html

The happinesses and stresses of full-time FOSS work

$jim is the reviewer for patches landing in $jim's tree, you're the reviewer for patches landing in your tree, etc. Part of the advantage of this workflow is that it's an informal, loose process. You send the patches to the mailing list, $jim reviews them and incorporates them into his tree, and anyone who trusts $jim pulls his tree and gets the patches.

If you disagree with $jim's changes to your patches, bring it up so that it can be fixed in later commits. Ideally $jim would only make tweaks to your patches, such as rebasing to reorder or merge or split up commits in a manner which makes more sense to him, or correcting typos or style errors as a courtesy. For any larger problems with the patchset, he's more likely to kick it back to you with feedback so you can amend the commits and send along a v2 at your discretion.

When I look into my crystal ball, I see $jim's tree, my tree, and perhaps dozens more, co-existing forever and pulling patches from each other as necessary. When you eventually deploy this to production, you'll probably end up hosting your own tree somewhere, planting a flag in the ground: this is the version of $project that we're running on $company production. When $othercompany makes improvements to their $project, you might pull changes from them, or in the other direction when you improve your branch. We use the mailing list to keep us informed of everyone else's work.

This is how Linux works - there are thousands of trees in the wild, from Linus' "upstream" tree, distro-specific trees, trees for individuals like Greg KH or even my tree, trees for larger kernel teams like linux-drivers, linux-dri (graphics), linux-ext4, etc. In fact, hardly anyone uses Linus' tree at all - your distro is running their own tree. The only time I use Linus' tree even as a kernel hacker is as a reasonably sane base to apply other patches to. Many kernel trees are even on GitHub and accept pull requests!

I wrote up my C style guidelines in detail:

https://git.sr.ht/~sircmpwn/cstyle

Sourcehut Q4 2019 financial report is out:

https://sourcehut.org/blog/2020-01-13-sourcehut-q4-2019-financial-report/