wlroots 0.10.0 has been released:
The happinesses and stresses of full-time FOSS work
Long explanation of distributed git workflows I sent to a client to explain the SourceHut approach
$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!
Status update, January 2020
grim 1.3.0 released:
Sway 1.3-rc3 released!
Sourcehut Q4 2019 financial report is out:
mako 1.4.1 released:
Initial groundwork for VRR in wlroots: https://github.com/swaywm/wlroots/pull/1987
Or alternatively, add some tests for interactive terminals.
Way Cooler Postmortem
Opened two big wlroots pull requests recently: the first one introduces a high-level scene-graph API, the other one introduces a low-level API to be able to use KMS planes. These will be the wlroots foundations for my long-term goal to use KMS planes to improve performance and battery usage.
sway 1.3-rc1 released:
wlroots 0.9.0 released:
Languages which are not C should not depend on C. A language design is much more compelling when its own compiler, runtime, stdlib, etc are self-hosting (i.e. written in the language itself). Constraining ourselves to a language design which can route all of its syscalls through the libc abstraction layer (which is THICK) constrains our language designs in ways I dislike.
Current status: trying to fix Go's charset handling