From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Greg KH <greg@kroah.com>
Cc: Theodore Ts'o <tytso@mit.edu>,
ksummit@lists.linux.dev, linux-fsdevel@vger.kernel.org
Subject: Re: [MAINTAINER SUMMIT] Adding more formality around feature inclusion and ejection
Date: Fri, 22 Aug 2025 16:19:27 +0100 [thread overview]
Message-ID: <d876450623204fa278bea8ffb7fbe1a20b0eecae.camel@HansenPartnership.com> (raw)
In-Reply-To: <2025082202-lankiness-talisman-3803@gregkh>
On Fri, 2025-08-22 at 14:03 +0200, Greg KH wrote:
> On Fri, Aug 22, 2025 at 09:09:04AM +0100, James Bottomley wrote:
> > So what I saw is that as developers exercised this and effectively
> > disengaged unless directly attacked, it pretty much became all on
> > Linus because no-one was left in the chain. This is precisely where
> > I think we could do with an alternative mechanism.
>
> You are implying here that we all just "ran away" and left Linus to
> hold the bag here, which is NOT the case at all. This specific issue
> has been discussed to death in a lot of different threads, public and
> private with lots of people involved and none of that would have been
> any different had we had some sort of "process document" ahead of
> time.
I didn't ask for a process document. I was clear about what I was
asking for in the part of the email you cut in your reply.
> So I don't think that attempting to codify the very rare occurances
> like this is going to really help out much, given that they are all
> unique to their time/place/subsystem based on our past history like
> this.
>
> > > Now, the above is inherently very messy. But fortunately, it's
> > > only happened once in thirty five years, and before we propose to
> > > put some kind of mechanism in place, we need to make sure that
> > > the side effects of that mechanism don't end up making things
> > > worse off.
> >
> > Well, what we ended up with is one person in the chain (Linus), no
> > actual decision except a failed pull request and nothing actually
> > said which has lead to a raft of internet speculation.
>
> It's not our job to quell "internet speculation", sorry.
I didn't say it was.
> Just because we normally work in public for almost everything,
> doesn't mean that some things can't be done in private as well. And
> again, just because you haven't seen a public decision doesn't mean
> that there hasn't been one made :)
I get that in the current political climate transparency is taking a
back seat. However, it does lie at the heart of the open in open
source so I think we should be making a bit more effort to be better.
Being transparent would have controlled (not quelled because there's
always conspiracy theorists) the internet speculation not because it
would make it someone's job but because it's simply a natural
consequence of doing the right thing.
Regards,
James
next prev parent reply other threads:[~2025-08-22 15:19 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
2025-08-22 15:19 ` James Bottomley [this message]
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=d876450623204fa278bea8ffb7fbe1a20b0eecae.camel@HansenPartnership.com \
--to=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