@marcan maybe @monsieuricon could have some ideas.

@marcan @Conan_Kudo @jacksonchen666 how do we manage to both provide a better workflow *and* avoid lock-in into an open-core tool like gitlab?

(I'm not trying to be contrary, this is literally my worry.)

@Conan_Kudo @vincent @marcan @jacksonchen666 a single point of failure platform is also not really acceptable. Imagine that you're sitting on a zero-day exploit of the Linux kernel and you want to prevent a fix from going out. Knocking out the central code management system is the logical move.

@Conan_Kudo @vincent @marcan @jacksonchen666 SMTP is not the only channel for passing around RFC2822 messages, though. However, it remains the only widely used distributed protocol for doing so.

@Conan_Kudo @jacksonchen666 @vincent @marcan no it isn't. If you knock out kernel.org, developers can still collaborate using the same process (email review) and put out a release that can be verified for authenticity by its digital signature.

@Conan_Kudo @jacksonchen666 @vincent @marcan kernel.org was offline for months in 2011 and Linux releases kept going out.

@Conan_Kudo @jacksonchen666 @vincent @marcan if the solution is to fall back to what we're doing now, then we've not really solved anything, just complicated the process and made it more fragile.

@Conan_Kudo @jacksonchen666 @vincent @marcan I'm not convinced this is accurate. It's easy to blame tooling, which is the most visible part of the process. However, I'm pretty sure if we replace this with the most amazing workflow of submitting and reviewing the code, we'll still be 90% in the same situation, because:

1. Writing kernel code is hard
2. Reviewing kernel code is even harder
3. Upstreaming to rapidly-moving mainline is the hardest

We need maintainers, preferably well-paid teams of maintainers, much more than we need a shiny code review toolset.

@marcan @Conan_Kudo @jacksonchen666

Everyone recognizes that the status quo is inefficient -- everyone just disagrees about how to fix it, and if "don't care if it's down for a month" is acceptable to you, it's not acceptable to many others.

I do have a foot in this dance -- I have been working on a workflow tool that makes it easy to submit patch series and participate in code review. My hope is that we can use evolutionary approach to improve the status quo.

https://b4.docs.kernel.org/en/latest/contributor/overview.html

I have a feeling that it may improve your life as a person who is trying to submit something to upstream.

(I do have a request -- please don't use obscenities in this conversation, because it just raises the emotional degree without actually bringing anything constructive to the table. I'm not really here to yell at anyone, so please don't yell at me.)

@raggi @Conan_Kudo @jacksonchen666 @marcan Yeah, but people problem is the hardest problem! Believe me, for every person who is raving about how much they hate the process, there's another person who raves how much they love the process for its decentralized, no-single-point-of-failure, everything-is-in-my-inbox kinds of features.

@raggi @Conan_Kudo @jacksonchen666 @marcan ActivityPub doesn't really bring us anything we don't already have with RFC2822 and SMTP, though. It's just another way of doing the exact same thing, with the exact same inherent problems.

ActivityPub is pretty new and niche, so it hasn't yet been fully abused by spammers and other bad actors, but as time goes on it *will* get all the same kinds of horrible spam-avoidance workarounds that make email seem lossy and unreliable. :(

@raggi @Conan_Kudo @jacksonchen666 @marcan I will agree with you regarding SMTP, but RFC2822 (the "email message" standard) is only a mess because it's old and full of questionable legacy workarounds that were necessary to deal with the early internet (7-bit SMTP protocols, mainly).

If we no longer need to worry about that legacy and can stick to the latest 8-bit-clean standard, the format is quite robust and solid.

@raggi @Conan_Kudo @jacksonchen666 @marcan JSON is great until you have to embed a string containing quotes, or some binary content, at which point you're basically doing all the same horrible things you have to do with email messages. :)

@raggi @Conan_Kudo @jacksonchen666 @marcan Oh, we have lots of standards. It's good, working implementations that are so hard to find. I mean, I just recently discovered that Python's email.message encoders are so broken, it's basically impossible to send a message with headers containing some unicode and not trip up some kind of 7-bit encoding bug.

@raggi @Conan_Kudo @jacksonchen666 @marcan What about "I want to go back to a discussion that happened 10 years later and still be able to view the entire thing?" And "fetch files by URI" is rife with faulty assumptions -- the "Universal" in "URI" means it's universally addressable, not universally retrievable.

It's a similar problem we already have today with pull requests, for example. If someone sends a pull request and the maintainer rejects it, we have no archive to go back to years later to investigate why it was rejected and what was submitted. I know it's a very niche concern, but as someone who wants to preserve and archive all aspects of kernel development process, I do care about saving this data.

@raggi @Conan_Kudo @jacksonchen666 @marcan Yeah, but compare this with "you can copy all of linux kernel development archives going back 25 years, and keep them continuously updated, if you like". This is possible with lore.kernel.org -- so I want a similar level of archival and distribution convenience offered for all other kernel development platforms.

@Conan_Kudo @jacksonchen666 @marcan while I could agree that the process is perfectible (and thanks to lei, b4 and lore @monsieuricon is getting better every month) putting forward the argument that "patch review by email sucks" doesn't help your cause, as it's a purely personal preference. I consider web-UI review a toy unsuitable for getting any serious work done, but I realize that I cannot use such argument to push back against any proposal to change to the status-quo as it mostly relates to my preferences/workflow/toolset/mindset.

So please, I'm honestly interested in reading where the discussion goes, but don't use such argument as it's purely a personal preference.

@marcan @Conan_Kudo @jacksonchen666 @monsieuricon let me add two points to your list:

- Tens of years of scripting/automation developers and maintainers have hand-grown to accommodate their workflows and from which it is hard to detach from.

And then if you want my perspective, as someone who approached kernel development with a background in webUI systems: sending patches by email is a tedious process, which requires you're in control of each single step. I've learned that doing things "slowly" is the only way one can keep up with the complexity of kernel development. I hate manually adding receivers to a formatted patch ready to be sent out, but that forces me to think about exactly who should receive the patch. I hate getting to v10 and gong through format/resend but that forces me to rebase and re-check every patch I send out. So yes, I guess the clunky process serves also to make sure you do check every little detail of the process, to make sure things are as "perfect" as possible.

So yes, I guess i definitely fall into your 3) point above. I've learned to love the struggle as it contributes to the overall quality of the end result.

@marcan @Conan_Kudo @jacksonchen666 @monsieuricon I'm not sure I know how to quote your post, by trying by points:

- the nitpicking non-sense: I completely disagree here :) code is maintainable if its consistent, and code is consistent if rules are enforced, including reverse xmas-tree nonsenses :) (I got grumpy the first time I've been told to change a patch to adhere to that rule. Now I (kindly) ask people to comply with that especially newcomers). This doesn't mean that a well styled but bad engineered piece of code is acceptable of course. But form is substance when roughly a few thousand people are messing with the same code repository at the same time.

- the argument that "perfection is the enemy of good" stands, I see your point and I've recently dealt with a community that would have a lot of code to upstream but simply don't want to go through that struggle as they don't see the effort justified. This isn't good for anyone, but I feel the culprit is maybe in the downstream development process. Upstreaming should be planned early, budgeted (in time and funds) accordingly, and should be clear that you're putting yourself forward for future maintainership and you are willing to help the community with reviews of other people's code. If those conditions are not met, for whatever reason, it's better to have that code downstream otherwise someone will have to maintain it on your behalf. Might sound harsh, but maybe lowering the bar would make it easier to "merge and forget" and put additional burden on the community without giving anything back ?

By the way, these are all questions I'm asking myself as well, I got very sad by the recent push-backs I've received when I suggested to upstream that code I mentioned and the message I got back was along the lines of "hell no, I'm not going to spend time moving comment lines around to satisfy your OCD, as my code works already" (surprise surprise, it works for that single use case but not for others, if they would have upstreamed they would have known :)

Thanks for the discussion though