Re: thoughts on a Merge Request based development workflow

[Konstantin Ryabitsev <konstantin@linuxfoundation.org>]

On Tue, Oct 08, 2019 at 01:39:02PM -0400, Don Zickus wrote:
>Regardless, I think what you wrote re-enforces the idea that emailing a
>patch series (and their vX followups) is messy for the maintainer and a
>more evolved idea is to let a forge take git-push as input.

I'm pretty opposed to the idea of forges, because this approach makes it 
very easy to knock out infrastructure critical to the project's ability 
to quickly roll out fixes. Imagine a situation where there's a zero-day 
remote root kernel exploit -- the attackers would be interested in 
ensuring that it remains unpatched for as long as possible, so we can 
imagine that they will target any central infrastructure where a fix can 
be developed and posted.

Currently, such an attack would be ineffective because even if 
kernel.org is knocked out entirely, collaboration will still happen 
directly over email between maintainers and Linus, and a fix can be 
posted on any number of worldwide resources -- as long as it carries 
Linus's signature, it will be trusted. If we switch to require a central 
forge, then knocking out that resource will require that maintainers and 
developers scramble to find some kind of backup channel (like falling 
back to email). And if we're still falling back to email, then we're not 
really solving the larger underlying problem of "what should we use 
instead of email."

We also shouldn't forget trigger-happy governments that like to ban 
troves of IP addresses in their chase after "the safe internet." Github 
has already been banned a couple of times in China and Russia, and 
chances are that this will continue.

This doesn't mean that forges are entirely out -- but they must remain 
mere tools that participate in a globally decentralized, 
developer-attestable, self-archiving messaging service. Maybe let's call 
that "kernel developer bus" or "kdbus" -- pretty sure that name hasn't 
been used before.

-K