From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
To: "Theodore Tso" <tytso@mit.edu>
Cc: Greg KH <greg@kroah.com>,
James Bottomley <James.Bottomley@hansenpartnership.com>,
ksummit@lists.linux.dev, linux-fsdevel@vger.kernel.org
Subject: Re: [MAINTAINER SUMMIT] Adding more formality around feature inclusion and ejection
Date: Mon, 25 Aug 2025 09:57:32 +0200 [thread overview]
Message-ID: <20250825095732.4571e6d0@foz.lan> (raw)
In-Reply-To: <20250822122424.GA34412@macsyma.lan>
Em Fri, 22 Aug 2025 08:24:24 -0400
"Theodore Tso" <tytso@mit.edu> escreveu:
> On Fri, Aug 22, 2025 at 02:03:13PM +0200, Greg KH wrote:
> The current baseline is that the media subsystem, networking, or BPF
> maintainer's decide what features to accept and who they will accept
> pull requests from.
On media, we typically place things that deserve more discussion under
staging. We did that for stateful decoders and encoders, for instance.
The same was done for stateless codecs. It means that any drivers written
to use such features also go to staging. Not always possible, but
something like that IMO serves to signalize to users, distro-maintainers
and the maintainers of such feature that, while we're ok to have it
being tested, we're yet seeing issues that need more discussions and/or
fixes.
> The same us true all the way up the hierarchy
> maintainer tree up to Linus. What is the alternative that we could
> use? That some democratic voting procedure, or some kind of core team
> would stick their oar into making this decision? I'm not sure that
> would be an improvement; in fact, IMHO, it will very likely be
> significantly worse.
Agreed. It is really hard to see when problems will arise, specially
in cases like this.
Thanks,
Mauro
next prev parent reply other threads:[~2025-08-25 7:57 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-21 8:56 James Bottomley
2025-08-21 16:27 ` Steven Rostedt
2025-08-21 17:44 ` James Bottomley
2025-08-21 19:15 ` Steven Rostedt
2025-08-22 7:59 ` James Bottomley
2025-08-21 19:32 ` Paul Moore
2025-08-22 11:39 ` Mauro Carvalho Chehab
2025-08-22 13:15 ` Matthew Wilcox
2025-08-21 20:34 ` Theodore Ts'o
2025-08-21 20:59 ` Theodore Ts'o
2025-08-21 22:21 ` Matthew Wilcox
2025-08-22 11:29 ` Mauro Carvalho Chehab
2025-08-22 8:09 ` James Bottomley
2025-08-22 12:03 ` Greg KH
2025-08-22 12:08 ` Rafael J. Wysocki
2025-08-22 12:24 ` Theodore Tso
2025-08-22 15:31 ` James Bottomley
2025-08-22 16:09 ` Theodore Tso
2025-08-25 8:20 ` Mauro Carvalho Chehab
2025-08-25 7:57 ` Mauro Carvalho Chehab [this message]
2025-08-22 15:19 ` James Bottomley
2025-08-23 1:03 ` dan.j.williams
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=20250825095732.4571e6d0@foz.lan \
--to=mchehab+huawei@kernel.org \
--cc=James.Bottomley@hansenpartnership.com \
--cc=greg@kroah.com \
--cc=ksummit@lists.linux.dev \
--cc=linux-fsdevel@vger.kernel.org \
--cc=tytso@mit.edu \
/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