Re: [Ksummit-discuss] Topics for the Maintainer's Summit

[Linus Torvalds <torvalds@linux-foundation.org>]

On Tue, Sep 3, 2019 at 6:29 AM Laura Abbott <labbott@redhat.com> wrote:
>
> It's great that we can share these workflows but it still feels like a
> bit of an anti-pattern that we even _need_ to do so.

I don't think we really can mandate some of the tooling details - and
details is what a lot of this is all about.

Some people have their workflow very much tied to some very personal
preferences - like particular email readers, editors etc.

Think back on the days when people used to read email inside of GNU
emacs and use a lot of the random Emacs functionality. There was no
way you could convince those people to do anything else ("everything
at my fingertips in the same environment") and there was no way you
could convince anybody else to use that crazy workflow.

I don't think there are a lot of those "everything inside GNU emacs"
people around any more, but some might exist, and even ignoring that
kind of thing, depending on which MUA you use some things are simply
<i>much</i> more convenient than others. I think a lot of us basically
live in our mail readers, and then it makes a huge difference whether
you're using Mutt or whether you're reading mail inside the web
interface of gmail. All those people who use automation from inside
their mail readers (much more limited than the GNU emacs example, but
still things like "pipe these 50 emails to Xyz") can't just be told
"now you have to use the web interface for patchwork and/or a tool
that downloads things that way.

I think some of the push-back to the GPU people wasn't from them not
inventing the group maintainership like Dave said, but from that being
presented as some kind of "this is the way to do it". When it's just
_one_ way to do it, and other groups have completely different
infrastructure and models..

So I don't think we can force some workflows.

We can force some ground rules. The whole "has to be in next" thing is
pretty separate from how the patches are managed, for example.

And "it has to be visible on a public list for review, and for
lore.kernel.org to archive the discussion, because things need not
just review, but _outside_ review" is pretty obvious for any big
changes.

But even that second "obvious" thing equally obviously cannot be
applied to _every_ patch. Even if you ignore the special embargo
cases, you just have a lot of patches that are local fixes, rather
than big new features. We can't tell people "you can't fix an obvious
bug without having it reviewd on the mailing list first". That would
be frustrating any sane developer if we tried to make that a hard
rule. So even the "obvious" workflow that we all think about for big
development simply can't be some kind of "this is how it must be done"
rule.

                      Linus