All of lore.kernel.org
 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 [Ksummit-discuss] [MAINTAINERS SUMMIT] Pull network and Patch Acceptance Consistency 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.