ksummit.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: media-submaintainers@linuxtv.org,
	ksummit-discuss@lists.linuxfoundation.org
Subject: Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Pull network and Patch Acceptance Consistency
Date: Fri, 14 Jun 2019 12:43:05 -0300	[thread overview]
Message-ID: <20190614124305.65eb8dbd@coco.lan> (raw)
In-Reply-To: <1560525785.27102.16.camel@HansenPartnership.com>

Em Fri, 14 Jun 2019 08:23:05 -0700
James Bottomley <James.Bottomley@HansenPartnership.com> escreveu:

> On Fri, 2019-06-14 at 12:11 -0300, Mauro Carvalho Chehab wrote:
> [...]
> > If you think this is relevant to a broader audience, let me reply
> > with a long answer about that. I prepared it and intended to reply to
> > our internal media maintainer's ML (added as c/c). 
> > 
> > Yet, I still think that this is media maintainer's dirty laundry
> > and should be discussed elsewhere ;-)
> > 
> > ---  
> 
> So trying not to get into huge email thread, I think this is the key
> point:
> 
> [...]
> > Currently, I review all accepted patches.  
> 
> This means you effectively have a fully flat tree.

Yes.

> Even if you use
> git, you're using it like an email transmission path.  One of the
> points I was making about deepening the tree is that the maintainer in
> the middle should trust the submaintainer they pull from, so there
> should be no need to review all the patches because of that trust. 

It is not a matter of trust. It is just that the media subsystem is
a complex puzzle. Just the V4L2 API has more than 80 ioctls.

So, the goal here is to do my best to ensure that patches will get
at least two reviews.

> This is how deepening the tree helps to offload maintainers because
> review is one of the biggest burdens we have and deepening the tree is
> a way to share it.  Without trust, we achieve no offloading and
> therefore no utility from deepening the tree.

Yeah, I know one day this won't scale. The day it happens, I'll
just start picking pull requests. As we already use git, a change 
like that would be trivial.

> So, to get back to the original question, which was *should* we deepen
> the tree: why don't you feel you can let branches with patches you
> haven't reviewed into your tree?  I've characterised it as a trust
> issue above, but perhaps it isn't. I think this is a key question which
> would help us understand whether a deeper tree model is at all
> possible.

One of the aspects is that developers nowadays are specialists on a
subset of the media devices. Most of them are working on complex 
camera support, with envolves a subset of the APIs we have. They
never worked on a driver that would use other parts of the API, like
DVB, Remote Controllers, TV, V4L2 streaming devices, etc.

So, having someone with a more generalist view at the end of the
review process helps to identify potential problems that might
affect other devices, specially when there are API changes involved[1].

[1] Since when I started maintaining the subsystem, back on 2005,
on almost every single Kernel review there are API changes in
order to support new types of hardware.

Thanks,
Mauro

  reply	other threads:[~2019-06-14 15:43 UTC|newest]

Thread overview: 77+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-06 15:48 James Bottomley
2019-06-06 15:58 ` Greg KH
2019-06-06 16:24   ` James Bottomley
2019-06-13 13:59     ` Mauro Carvalho Chehab
2019-06-14 10:12       ` Laurent Pinchart
2019-06-14 13:24         ` Mauro Carvalho Chehab
2019-06-14 13:31           ` Laurent Pinchart
2019-06-14 13:54             ` Mauro Carvalho Chehab
2019-06-14 14:08               ` Laurent Pinchart
2019-06-14 14:56             ` Mark Brown
2019-06-14 13:58           ` Greg KH
2019-06-14 15:11             ` Mauro Carvalho Chehab
2019-06-14 15:23               ` James Bottomley
2019-06-14 15:43                 ` Mauro Carvalho Chehab [this message]
2019-06-14 15:49                   ` James Bottomley
2019-06-14 16:04                     ` Mauro Carvalho Chehab
2019-06-14 16:16                       ` James Bottomley
2019-06-14 17:48                         ` Mauro Carvalho Chehab
2019-06-17  7:01                           ` Geert Uytterhoeven
2019-06-17 13:31                             ` Mauro Carvalho Chehab
2019-06-17 14:26                               ` Takashi Iwai
2019-06-19  7:53                               ` Dan Carpenter
2019-06-19  8:13                                 ` [Ksummit-discuss] [kbuild] " Philip Li
2019-06-19  8:33                                 ` [Ksummit-discuss] " Daniel Vetter
2019-06-19 14:39                                   ` Mauro Carvalho Chehab
2019-06-19 14:48                                     ` [Ksummit-discuss] [media-submaintainers] " Laurent Pinchart
2019-06-19 15:19                                       ` Mauro Carvalho Chehab
2019-06-19 15:46                                       ` James Bottomley
2019-06-19 16:23                                         ` Mark Brown
2019-06-20 12:24                                           ` Geert Uytterhoeven
2019-06-20 10:36                                         ` Jani Nikula
2019-06-19 15:56                                       ` Mark Brown
2019-06-19 16:09                                         ` Laurent Pinchart
2019-06-15 10:55                         ` [Ksummit-discuss] " Daniel Vetter
2019-06-14 20:52               ` Vlastimil Babka
2019-06-15 11:01               ` Laurent Pinchart
2019-06-17 11:03                 ` Mauro Carvalho Chehab
2019-06-17 12:28                   ` Mark Brown
2019-06-17 16:48                     ` Tim.Bird
2019-06-17 17:23                       ` Geert Uytterhoeven
2019-06-17 23:13                       ` Mauro Carvalho Chehab
2019-06-17 14:18                   ` Laurent Pinchart
2019-06-06 16:29   ` James Bottomley
2019-06-06 18:26     ` Dan Williams
2019-06-07 20:14       ` Martin K. Petersen
2019-06-13 13:49         ` Mauro Carvalho Chehab
2019-06-13 14:35           ` James Bottomley
2019-06-13 15:03             ` Martin K. Petersen
2019-06-13 15:21               ` Bart Van Assche
2019-06-13 15:27                 ` James Bottomley
2019-06-13 15:35                 ` Guenter Roeck
2019-06-13 15:39                   ` Bart Van Assche
2019-06-14 11:53                     ` Leon Romanovsky
2019-06-14 17:06                       ` Bart Van Assche
2019-06-15  7:20                         ` Leon Romanovsky
2019-06-13 15:39                   ` James Bottomley
2019-06-13 15:42                   ` Takashi Iwai
2019-06-13 19:28               ` James Bottomley
2019-06-14  9:08               ` Dan Carpenter
2019-06-14  9:43               ` Dan Carpenter
2019-06-14 13:27               ` Dan Carpenter
2019-06-13 17:27             ` Mauro Carvalho Chehab
2019-06-13 18:41               ` James Bottomley
2019-06-13 19:11                 ` Mauro Carvalho Chehab
2019-06-13 19:20                   ` Joe Perches
2019-06-14  2:21                     ` Mauro Carvalho Chehab
2019-06-13 19:57                   ` Martin K. Petersen
2019-06-13 14:53           ` Martin K. Petersen
2019-06-13 17:09             ` Mauro Carvalho Chehab
2019-06-14  3:03               ` Martin K. Petersen
2019-06-14  3:35                 ` Mauro Carvalho Chehab
2019-06-14  7:31                 ` Joe Perches
2019-06-13 13:28       ` Mauro Carvalho Chehab
2019-06-06 16:18 ` Bart Van Assche
2019-06-14 19:53 ` Bjorn Helgaas
2019-06-14 23:21   ` Bjorn Helgaas
2019-06-17 10:35     ` Mauro Carvalho Chehab

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=20190614124305.65eb8dbd@coco.lan \
    --to=mchehab+samsung@kernel.org \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=ksummit-discuss@lists.linuxfoundation.org \
    --cc=media-submaintainers@linuxtv.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