ksummit.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Theodore Tso <tytso@mit.edu>, Greg KH <greg@kroah.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 10:20:48 +0200	[thread overview]
Message-ID: <20250825102048.754ee0a2@foz.lan> (raw)
In-Reply-To: <62aea685546cee80b18cfd7e1ea50b1a590d5edd.camel@HansenPartnership.com>

Em Fri, 22 Aug 2025 16:31:49 +0100
James Bottomley <James.Bottomley@HansenPartnership.com> escreveu:

> Well I did ask for two concrete things, but I can certainly repeat:
> 
> On Fri, 2025-08-22 at 09:09 +0100, James Bottomley wrote:
> >  I think I'd be happy if we sort out two things
> > 
> >    1. That the decision be taken by more than one person rather than
> >       abdicating to last man standing
> >    2. The outcome be documented clearly.

There are some aspects here:

- Who will communicate the decision? 

The way I see, the best would be if this would be done by the subsystem 
maintainers who accepted/acked the feature addition.

- Who will be involved on such discussion?

I'd say the subsystem core maintainers and developers plus the top 
maintainer and eventually TAB. Feature removal may cause troubles 
to distro maintainers, as some may have it enabled as well. So,
better having more people know in advance.

- How this will be documented?

Depending on the reasons why a feature is dropped, e.g. if it
involves personal data, I don't think the entire process can be
transparent, but surely a sanitized summary should be documented.

IMHO, the best way to document it is at the patch dropping such
feature, which will explain why the feature is removed. IMO, the
best would be to have such patch containing SOB from multiple
people:

- core subsystem developers and maintainers;
- Ack or SOB by the top level maintainers, if pertinent.

Thanks,
Mauro

  parent reply	other threads:[~2025-08-25  8:20 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 [this message]
2025-08-25  7:57         ` Mauro Carvalho Chehab
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=20250825102048.754ee0a2@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