On Thu, 2025-08-21 at 16:34 -0400, Theodore Ts'o wrote:
> On Thu, Aug 21, 2025 at 09:56:15AM +0100, James Bottomley wrote:
> > I think the only point of agreement on this topic will be that how
> > bcachefs was handled wasn't correct at many levels. I think this
> > shows
> > we need more formality around feature inclusion, including a
> > possible
> > probationary period and even things like mentorship and we
> > definitely
> > need a formal process that extends beyond Linus for deciding we can
> > no
> > longer work with someone any more.
>
> I think we are conflating three different things in this discussion
> thread, and it would be helpful if we separated them out.
>
> 1. What is the process by which a particular feature be included
> or ejected?
> 2. What is the process by which a developer should be excluded
> from the deevlopment community? And this goes beyond
> Code of Conduct violations, but in the case of a maintainer,
> when that person has displayed toxic tendencies which are
> sufficiently bad that other deevlopersa and maintainers refuse to
> work with the individual, and when that person has been accused of
> promoting a toxic environmet which is harming the entire
> community?
> 3. The question of maintainer mentorship, which is very different
> from (2) as there are a large set of skills which a much
> broader
> front including avoiding maintainer burnout, the product management
> side of being a maintainer (e.g. working with companies to
> motivate them to invest in a featrue which benefits not only the
> companies' business interest, but the community as a whole),
> managing volunteer, etc.
>
> (2) is a very hard problem, and so there is a tendency to focus on
> solving problems (1) and (2). However, using bcachefs and its
> maintainera as a motivating case for solutions to address (1) and (3)
> very likely going to result in skewing the discussion around the best
> ways of addressing (1) and (3).
I agree that 1 (at least for inclusion) and 3 are pretty much in hand:
1 runs by itself naturally and Steve wants to do 3.
> As far as (2), our baseline way of handling things is quite ad hoc.
> At the moment, individual developers will simply refuse to work
> someone who is accused of being toxic, by doing things such as:
>
> (a) using mail filters to redirect e-mail from that person
> to /dev/null,
> (b) telling a higher-level maintainer that because of (a) they
> would appreciate it if any pull requests from that individual
> include changes to their subsystem or sub-subsysttem,
> that those commits should be presumed to be auto-NACK'ed,
> and requesting that the PULL request should be rejected,
> (c) if the behaviour of said person exasperates a higher-level
> maintainer to such an extent that the higher-level maintainer
> refuse to accept patches or pull requests from said
> individual, and
> (d) informing program committees of invite-only workshops and/or
> conferences that if that individual attends, they will refuse
> to attend because of that individual's toxicity.
>
> I will note that (b) and (c) can be appealed to someone higher up on
> the maintainer hierarchy, unless that higher-level maintainer is
> Linus, at which point there is no higher level authority to take that
> appeal, and that (b), (c), and (d) are effectivly a way that
> developers and maintainers are effectively saying, "it's either him
> or me!",
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.
> and as someone who has to manage volunteers, if a sufficiently
> large number of volunteers are sufficiently p*ssed off that they are
> threatening to withdraw, the wise maintainer (or program committee)
> should take heed.
>
> 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.
I agree whatever gets put in place will be messy, I just think it could
be a bit less messy and a bit more definitive.
> There is the saying that "bad facts make bad law", and the specifics
> of this most recent controversy are especially challenging. I would
> urge caution before trying to create a complex set of policies and
> mechanim when we've only had one such corner case in over 35 years.
The banks were very keen on not being stress tested before 2008 and we
all saw where that lead. The crisis forced them to confront the issue,
which does argue that when something like this comes along you take the
opportunity to improve. I'm also not arguing for a labyrinthine
process. 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.
Regards,
James
