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).
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!", 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.
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.
Cheers,
- Ted
