Re: thoughts on a Merge Request based development workflow

[Don Zickus <dzickus@redhat.com>]

On Tue, Oct 08, 2019 at 03:05:27PM -0400, 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."
> 
> 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.

If we flipped it around and used today's git-pull-request emails as trigger
for forges to run their services, does cover some of your concerns?

git-pull-request emails can skip the patch-translation layer (like
patchwork), run the automated tests, and utilize the current maintainer
workflows.

The email issue is hard to resolve as some folks feel like it should be a
primary vehicle while others feel it should be a secondary vehicle.

Cheers,
Don