Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance

[Linus Walleij <linus.walleij@linaro.org>]

On Thu, Sep 13, 2018 at 2:08 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:

> If there's a very significant part of the work that is
> done by the maintainer of a given subsystem, and that there is a
> single maintainer for that subsystem, what will happen when that
> maintainer decides to stop contributing for some reason?
>
> All the knowledge they built, experience they got (including at
> reviewing) is gone, possibly forever, and there's no one to pick up
> the subsystem, and the code is left to rot.

Unfortunately this is what happened when David Brownell
passed away. His passing had a long-standing and serious
impact on the quality of the subsystems he helped creating.

GPIO was left unmaintained and patches were coming in
and merged by Andrew Morton, as is default (and it is a
good thing that we don't just stop merging code, that would
probably have been even worse). Most of it was fine.

However one piece that got merged at this turbulent time
was the GPIO sysfs ABI which in my opinion
was not very nice. The main problem was that it exposed
kernel internals (the global GPIO numberspace) to the whole
world and made them semi-ABI which is really tricky to
maintain in the long run. It probably didn't seem like a big
problem at the time and GPIO was seen as obscure. But
it has created a major maintenance headache, and I imagine
that an active maintainer would have come up with something
a bit different. I have moved that ABI to "obsolete" and try
to make the new character device ABI as tasty as possible
to encourage migration but it will have to be maintained
until there is noone left in the forest to hear the tree fall
when I cut it. I guess in 2045 or so.

There are other things that was David's ideas, such as highly
optimized bit-banging routines in SPI where it would have
been great to have his input. Those are less severe, but I
can't help to compare with the MMC/SD subsystem where at
one point last year I could reach out to the previous-to-previous
maintainer (Pierre Ossman) and ask why the subsystem had
a bounce buffer mechanism, which was really helpful because
he quickly provided the answer and we managed to fix it up
nicely (commit bd9b902798ab).

Yours,
Linus Walleij