ksummit.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@intel.com>
To: Linus Torvalds <torvalds@linux-foundation.org>,
	Laura Abbott <labbott@redhat.com>
Cc: Bjorn Helgaas <helgaas@kernel.org>,
	"ksummit-discuss@lists.linuxfoundation.org"
	<ksummit-discuss@lists.linuxfoundation.org>
Subject: Re: [Ksummit-discuss] Topics for the Maintainer's Summit
Date: Thu, 05 Sep 2019 10:01:26 +0300	[thread overview]
Message-ID: <87o8zzw7jt.fsf@intel.com> (raw)
In-Reply-To: <CAHk-=wh1v7FK_VctdRo3fsuHJU4Dm95siC=vM9seuuapBgdg+A@mail.gmail.com>

On Tue, 03 Sep 2019, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> 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..

At least I've tried (and likely also failed) to merely describe what we
do, what works for us, how we think we benefit, and how it just might
benefit others. It's just sad when the pushback is strong enough to
discourage people from sharing their experiences to begin with.

I know I've reduced talking about it outside of the GPU people bubble.

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

Okay, I'll stick my neck out again.

In i915 it *is* a hard rule you can't push anything unless it was posted
and reviewed on the public list and passed CI first. No exceptions. Sure
it can be frustrating, but it's also so much less embarrassing when the
bug in the obvious fix gets caught in review/CI rather than in
mainline. And you tend to work on improving your process instead of
making more exceptions and taking shortcuts.

And since I'm one of those pesky "GPU people", YMMV a thousand times
over. ;)


BR,
Jani.

-- 
Jani Nikula, Intel Open Source Graphics Center

  parent reply	other threads:[~2019-09-05  7:00 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-30  3:17 Theodore Y. Ts'o
2019-08-30 12:01 ` Wolfram Sang
2019-08-30 13:58 ` Shuah Khan
2019-08-30 14:36   ` shuah
2019-08-30 13:58 ` Bjorn Helgaas
2019-09-02 15:09   ` Shuah Khan
2019-09-02 20:42   ` Dave Airlie
2019-09-02 22:22     ` Theodore Y. Ts'o
2019-09-03  2:35       ` Olof Johansson
2019-09-03  3:05         ` Randy Dunlap
2019-09-03 13:29       ` Laura Abbott
2019-09-03 16:07         ` Linus Torvalds
2019-09-03 17:27           ` Konstantin Ryabitsev
2019-09-03 17:40             ` Bjorn Helgaas
2019-09-06 10:21               ` Rob Herring
2019-09-19  1:47                 ` Bjorn Helgaas
2019-09-19 20:52                   ` Rob Herring
2019-09-20 13:37                     ` Mark Brown
2019-09-03 17:57             ` Mark Brown
2019-09-03 18:14             ` Dan Williams
2019-09-03 21:59             ` Wolfram Sang
2019-09-04  8:34             ` Jan Kara
2019-09-04 12:08             ` Laurent Pinchart
2019-09-04 13:47               ` Konstantin Ryabitsev
2019-09-05  8:21                 ` Jani Nikula
2019-09-06 10:50                   ` Rob Herring
2019-09-06 19:21                     ` Linus Torvalds
2019-09-06 19:53                       ` Olof Johansson
2019-09-09  8:40                         ` Jani Nikula
2019-09-09  9:49                           ` Geert Uytterhoeven
2019-09-09 10:16                             ` Konstantin Ryabitsev
2019-09-09 10:59                               ` Geert Uytterhoeven
2019-09-09 12:37                                 ` Konstantin Ryabitsev
     [not found]                     ` <20190911095305.36104206A1@mail.kernel.org>
2019-09-11 11:03                       ` Christoph Hellwig
2019-09-13  8:19                       ` Matthias Brugger
2019-09-05  7:01           ` Jani Nikula [this message]
2019-09-05 15:26             ` Theodore Y. Ts'o

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87o8zzw7jt.fsf@intel.com \
    --to=jani.nikula@intel.com \
    --cc=helgaas@kernel.org \
    --cc=ksummit-discuss@lists.linuxfoundation.org \
    --cc=labbott@redhat.com \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox