For Asahi, I contribute code across the entire stack: from bootloaders to the kernels to libraries to desktop environments to web browsers. I keep saying the Linux kernel development process is horrible, so what about the rest?

Let's talk about a project that does things right. KDE is a project of comparable scale to the Linux kernel. Here it its patch submission process:

1. I write the patch
2. I open the merge request *
3. The maintainer directly suggests changes using the interface, fully integrated with gitlab.
4. I click a button to accept the changes. They get turned into Git commits automatically. I don't even have to manually pull or apply patches.
5. I ask about Git history preferences, get told to squash them.
6. git pull, git rebase -i origin/main, clickety click, git push -f (I wouldn't be surprised if there's a way to do this in the UI too and I just don't know)
7. They merge my MR.

The whole thing took like 5 minutes of mental energy total, once the initial patch was ready.

Seriously, look at some of the timetamps. It wasn't even 15 minutes of wall clock time from the first suggestion to final commit. Less than an hour from opening the MR. And then it got merged the next day.

And this is why I love contributing to KDE and why they're our flagship desktop environment. :)

* This of course does not consider one-time setup costs. For KDE, that was opening up an Invent account, which takes 5 minutes, and I didn't have to learn anything because I already know GitLab and anyone familiar with any forge will quickly find their way around it anyway. The kernel, of course, requires you to learn arcane processes, sign up for one or more mailing lists, set up email filters, discover tools like b4 to make your life less miserable, manually configure everything, set up your email client with manual config overrides to make it handle formatting properly, etc., and none of that is useful for any project other than the small handful that insist in following the kernel model.

@marcan I've only contributed a bit of code to KDE but it was a much smoother process than LKML. Much like basically everything that is actively maintained and uses an interface like GitLab.

@marcan leave a comment with a line that is /rebase. Can be the only text, then it is silent and doesn’t leave a comment but rebases anyways.

Locally you git pull --rebase

If the project is configured a certain way, this shows up as a button

@ZiggyTheHamster The goal there was the squash though (hence interactive rebase), can it do that?

@marcan add comment "/rebase" against your MR and GitLab will take a care of the rest.

Just a tip, if you would like to save couple of commands in the shell. 🙂

@scrool But can it squash?

@marcan
Meanwhile FreeDesktop and the like:
- Get stuck on their Gitlab because they locked down it so much to counter spam that you'd need to ask each project for access (of course with the "Request Access" button of Gitlab not being appropriate)
- Send the patch to their mailing-list
- Few days later have to explain that their setup is near impossible to use, and also send URL to the commit in case they don't into email

Bare mailing-list sucks (you can have email with CIs btw) but having to interact with the various Gitlab setups is horribly annoying.
And if there's one thing email has perfected over the ages it's spam mitigation for everyone, while on Gitlab it's a proprietary Enterprise addon.

@lanodan The fd.o infra problems are very specific problems though, which can be solved. It's not a systemic community issue like the Linux kernel. We talked a bunch about that at XDC.

@marcan same thing for ffmpeg imo, although a bit less arcane.

Had a patch fixing window capture with GDI on Windows and adding a new config option for it, but it's still a year and i haven't submitted it because pains with email and stuff.

@marcan I think there's a pretty relevant difference in overall community philosophy here.

In KDE we don't really have formal maintainership over subprojects. Some parts have a single de-facto maintainer, others have more of an informal team of core contributors or no maintainers at all (just some people who take care of patches that are not otherwise taken care of). This alone probably reduces the amount of maintainer egotism.

@marcan We also don't gatekeep write access to a part of the code behind maintainership.

Any KDE developer with commit access can commit to any KDE code, relying on social control and peer review. One usually gets that access after just a handful of contributions.

@marcan That's not to say there are never bad experiences trying to contribute to KDE, but overall I'm pretty proud of our approach and pretty sure KDE isn't known to the world for being a particularly toxic community

@nicofee @marcan Also worth mentioning: while there are obviously exceptions (there are repos where only a smaller list of people have write access), they are much fewer than some people would expect.

There isn't anything like "oh KWin is too much of a core component so only the Core Team can push there". Restricted repos are mainly websites and other code that gets automatically deployed into servers. *All* of the actual C++ code that gets shipped to end users is open for all KDE committers.

Has this caused problems? Sometimes yes, but in the same way that anyone-can-edit causes problems in Wikipedia. If someone screws up, talk to them and revert. It's not a big deal and doesn't justify gatekeeping.

@nicolas17 @nicofee @marcan I remember once adding all of kwin to the koffice repo... Back in the CVS days.

@marcan I've had timely responses in the DRM subsystem and constructive interactions because they use GitLab.

Trying to report a kernel bug via email never once got feedback (except for the one time where a Lenovo employee put in their weight).

For me everything points in the same direction: those rejecting modern tools like GitLab are gatekeepers, hiding immense complexity behind the pseudo argument of "accessibility".

Thankfully a lot of other projects do it right.

@a_lex_ander @marcan I must say that GitLab (and GitHub) have heavy web pages (full of JavaScript) just to print some basic information like the discussion around a pull/merge request, etc. Also, you must be always connected to the Internet to access them.

What I would like is a offline-first, distributed platform with a seamless integration with a simple-yet-complete web UI.

I mean, we already have something like that for the git repository itself. If issues, pull requests, discussions, etc. everything is reachable via `git pull`, then everyone can use their favorite client (cli, simple gui, fancy web page). And they can still work even in an airplane.

@enrico204 @a_lex_ander

I must say that GitLab (and GitHub) have heavy web pages (full of JavaScript) just to print some basic information like the discussion around a pull/merge request, etc.

No, they have all that stuff to implement all the useful stuff they do, which is a lot more than that.

What I would like is a offline-first, distributed platform with a seamless integration with a simple-yet-complete web UI.

No you don't. Distributed platforms with that level of complexity are extremely hard to build. There's a reason why the kernel community keeps building centralized tools to work around the brokenness of their "distributed" email workflow (which runs on centralized mailing lists).

I mean, we already have something like that for the git repository itself. If issues, pull requests, discussions, etc. everything is reachable via git pull, then everyone can use their favorite client (cli, simple gui, fancy web page). And they can still work even in an airplane.

And then how do you handle merge conflicts for this mess? Think about it.

I don't know why people keep bringing up distributed/decentralized systems as if we need a new utopian solution to convince the kernel people. The kernel people don't want change because they don't want change. Decentralized stuff is just an excuse. We have working solutions that are a massive improvement over the kernel status quo, and the regression of centralization is minuscule in comparison. Please, let's stop with the decentralization story. Nobody else in FOSS has a problem with centralized forges.

@nicolas17 @nicofee @marcan drm-misc commit rights works the same way, which is the catch-all for small drivers and shared code

unfortunately still with the mail based tooling but fingers crossed on that to change too. it's been the plan for years at least

@a_lex_ander @marcan

>> those rejecting modern tools like GitLab are gatekeepers,

Would like to mention one subtle nuance here. Over at ardour.org, we *refuse* to use non-self hosted systems like Github/Gitlab as our *canonical repository*. We believe that historical experience at sourceforge and direction at github confirm the wisdom of our preference for self-hosted options.

However, we are happy to use github as a public-facing locus for PRs.

@PaulDavisTheFirst @a_lex_ander Which is perfectly fine, of course. I've never had any issues sending you PRs. You can cook things however you want internally; as far as the outside world is concerned, you're on GitHub and that's what matters :)

Nit: GitLab is self-hostable (though rather heavy-weight). I personally prefer Gitea for self-hosting.

@sima @nicolas17 @nicofee @marcan what would you mean by non mail based tooling?

@conor @nicofee @marcan @nicolas17 gitlab merge requests

https://lwn.net/Articles/773456/

@sima @nicofee @marcan @nicolas17 If you switch to those, how would you interact with the rest of the kernel?

@conor @sima @nicofee @nicolas17 Same way we already do, by sending pull requests upwards. The kernel figured out a long time ago that email doesn't scale and fixed it for maintainers, it just decided to keep the pain for everyone else for no reason. Now we're fixing that part.

My soc/apple tree is already on GitHub and flows directly to soc that way, I just don't take PRs right now. This means we start taking PRs. Simple as that.

@marcan @sima @nicofee @nicolas17 What I mean is, if you have some changes that affect both drivers/soc/apple and, idk, drivers/dma, how do you interact with the relevant maintainers for that code?

@marcan @nicofee @nicolas17 @sima (and this isn't some antagonistic questioning shit, I actually want to know how that's going to work)

@conor @nicofee @marcan @nicolas17 cross-forge merge requests will stay email based and work exactly like they do now. git should maybe gain a cross server merge request protocol to make this work neater, but that's just a nice to have

cross-forge changes likely also need to fall back to mail. in the case of drm that's a really small part of the overall volume, if we get drm-misc and the big drivers all moved to gitlab

@sima @nicofee @marcan @nicolas17 it'd be nice of the email fallback was automated via get_maintainer and hooked into a b4-relay type thing, so that contributors don't need to give a shit about what is and what isn't cross forge.

Also, since I'm not a DRM contributor, is drm-misc where the dt based stuff for arm etc ends up? That's probably quite a big chunk of where your cross subsystem/forge stuff is, given there's very often bindings & devicetree changes mixed in with drivers?

@conor @nicofee @marcan @nicolas17 yeah there's room for some scripting in both directions

dt bindings land through driver trees, but need a dt maintainer ack. so we just need to drag a dt maintainer onto our forge and done

@sima @nicofee @marcan @nicolas17 unfortunately I know how things work for dt-bindings, and drag may be an apt word ;)

@marcan This is an unfair comparison. There are plenty of projects where contributing via email is way easier than contributing via GitHub/GitLab. The core problem is not the tooling.

@marcan My experience with GitLab:

- Register on their GitLab instance
- Wait for confirmation email
- Ask for manual admin account approval
- Add SSH key
- Fork, setup remotes for upstream and forked project
- Push buttons to open MR

My experience with sr.ht:

- Just a single `git-send-email -1 --to=whatever`
- No registration, no setup, no nothing

@marcan Disclaimer: I work at sr.ht

@gregorni I have not. Kind of got turned off by some of the attitudes I saw in their bug tracker (longstanding issues going unfixed even when the fix is trivial and a patch was posted because "they don't support third party themes", stuff like that...)

@drewdevault

https://openhub.net/p/kde

vs

https://openhub.net/p/linux

And 4 million lines of Linux are autogenerated AMD GPU register list spam, so probably shouldn't count.

@jani https://b4.docs.kernel.org/en/latest/contributor/send.html is something like this. It's not bad but still a bit involved. The best thing about it is that it makes patches much more consistent, assuming the endpoint is used. You still need some bespoke patch state tracker to the likes of Patchwork though.

Sr.ht has all of that integrated - your ml archive is basically a first class patch state tracker.

@jani @marcan what exactly is lossy in email?

@jani @marcan For sure, email tooling leaves a lot to be desired and can be improved, yeah. Working on it!

@emersion
@marcan while submitting is genuinely that easy, I don't think the rest of the workflow is nearly as smooth as we hope for here.

I've seen mail clients fuck up the To: and/or Cc: so replies don't make it onto the list, I don't think any mail client will get formatting "right" the first time (whatever "right" is in 2023), no tool will keep track of your revisions for free, and I believe the problems described at https://git.sr.ht/~roseh/patchy are still around in general. To take Hector's example, 1-click feedback application isn't something that everyone can take advantage of over email. These problems show up after submission.

@emersion From my experience working on Patchwork - you lack a unique identifier for your patches. If you work with forges and git repos that's your fork and a branch. You could use Gerrit-like Change-Id but that's also bad.

This leads to a few issues:

1. Bad email providers mangling your stuff are becoming increasingly common

2. Combining patches into a series is harder. Especially if people use weird settings like unthreaded sending.

3. Updating the series is hard. Sending a v2 patch? Resending the series? Which version is the newest? What was superseded.

4. Applying the series to a newer version of the tree is more prone to failing than a rebase.

I guess a lot of that can be solved if sent patches are ingested immediately and after that you work directly with the resulting git branch.

@marcan Unfortunately, this is not my experience with KDE.

My first rather simple bugfix in an obscure corner of the codebase was merged only after I sniped the responsible dev on their matrix.

The second bugfix was merged quickly, probably because it fixed a cosmetic visual problem introduced in the most recent release.

The remaining four or so more substantial PRs have been lingering since February, waiting for someone to take an interest in them.

@marcan About a month ago, I was asked if I was interested in continuing work on one of these PRs, and if not, if I would allow someone else to continue. Needless to say, any interest I had in improving KDE has long since withered away, and both sides of that conversation knew how embarrassing the whole thing was.

@wolfpld That's unfortunate :(

Sounds like you got stuck with a part of the project that didn't get much attention... honestly though, that's still more understandable than the trainwreck that is contributing to Linux.

@jani @emersion @marcan but you stated that email is lossy. What exactly is “lossy”?

@ivyl All valid points. (1) and (2) are fixed by using a good email provider. (3) fixed by better tooling. (4) fixed by base tree info (https://git-scm.com/docs/git-format-patch#_base_tree_information) which is a pain with current tooling but can be fixed.