Re: thoughts on a Merge Request based development workflow

[Laura Abbott <labbott@redhat.com>]

On 10/8/19 3:05 PM, Konstantin Ryabitsev wrote:
> 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."
> 

I'd argue that e-mail as a backup solution is perfectly fine. The issue
with e-mail is that it's not scaling. If something did happen and we
needed to temporarily move back to e-mail, chances are it would be
at a smaller scale.

> 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.
> 

We've had this problem with e-mail spam filtering too. Any sort
of system seems likely to have this problem of needing to block
unwanted content but purposely or not blocking non-malicious
content.

> 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.
> 

The big issue I see with anything decentralized is that as things
grow people don't actually want to host their own infrastructure.
Think about the decline in the number of people who host their own
e-mail server. Anything decentralized would still presumably require
a server somewhere, so you're going to either raising the bar to entry
by requiring people to set up their own server or end up with people
still relying on a service somewhere. This feels like it ends up with
the situation we have today where most things are locally optimized
but on average the situation is still lousy.

You've articulated you've articulated the reasons against centralization
very well from an admin point of view (which I won't dispute) but at
least from a user point of view a centralized forge infrastructure is
great because I don't have to worry about it. My university/company
doesn't have to set anything up for me to contribute. I get we are
probably going to end up optimizing more for the maintainer here but
it's worth thinking about how we could get forge-like benefits where
most users don't have to run infrastructure.

Thanks,
Laura