On Thu, Sep 13, 2018 at 02:57:23PM +0200, Alexandre Belloni wrote:
> On 13/09/2018 14:08:11+0200, Maxime Ripard wrote:
> > On Wed, Sep 12, 2018 at 08:44:52PM +0200, Thomas Gleixner wrote:
> > > On Wed, 12 Sep 2018, Alexandre Belloni wrote:
> > > > On 12/09/2018 11:14:14+0200, Linus Walleij wrote:
> > > > I'm not saying there aren't any issues and that the level of reviews is
> > > > sufficient but I really don't think problematic maintainers are as
> > > > widespread as Daniel claims. It is really getting tiring to see him
> > > > show random statistics and draw wrong conclusions from them.
> > > 
> > > Agreed. Lies, damned lies and statistics...
> > > 
> > > The really interesting metric would be bugs/nr_commits. That gives you
> > > valuable information how good your subsystem works and interacts with the
> > > rest of the kernel.
> > 
> > That's one angle to look at it, and I agree it would be a pretty good
> > overview of how good a maintainer is at reviewing patches, in general.
> > 
> > However, there's different angles where the metric used by Daniel
> > makes sense. 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?
> > 
> 
> Daniel's metric (at least the one he used to gauge RTC) will never ever
> be the good one. He simply looked at my contributions versus the top
> contributors. The reality is that I'm taking more contributor patches
> than I write.
> 
> If you have a look at the DRM statistics I gave, the situation is
> actually quite similar. Contribution for each driver is massively
> dominated by its maintainer. For the big ones (i915, amd, exynos), if
> the company decides to stop developing the driver, it will be
> completely dead. For the small one they basically only have one real
> contributor.
> 
> > 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.
> > 
> 
> And this is almost the same for the DRM core where Daniel is by far the
> top contributor.

DRM is far from perfect. No one ever said it was, and I disagree on
some of the solutions that were implemented there. However, having
imperfect solutions doesn't make the underlying problem go away.

> > Maintainers burn-out are also a thing, that is only reinforced by
> > being the sole one caring for that subsystem.
> > 
> > And then, you also have the issue that nothing prevents that
> > maintainer to enforce particuliar rules and thus prevent contributors,
> > reinforcing the fact that they would be the sole maintainer for that
> > subsystem.
> 
> This is a real issue. What I'm saying is that it is not that common.

Yet you have first-hand experience with at least two of them.

And it's *one* symptom of the same upstream issue. The fact that you
can't have a quite holiday without drowning in mails when you go back,
or that you can't take a break from the kernel for whatever reason
without putting the code you maintained and cared for for so long is
another one.

> > As a community, we should care about those issues as well. Basically,
> > the whole Linus discussion should apply at all the levels of the
> > hierarchy, for pretty much the same reasons.
> > 
> > Having multiple maintainers and / or a more even spread of the
> > contributions mitigate all these. So Daniel's metric is a pretty good
> > one, and it doesn't mean that a particular maintainer is bad at their
> > job, or is not making any effort, or shouldn't be praised. It really
> > is a different metric, for a different issue.
> 
> It is a very biased metric that will show in a bad light any subsystem
> that has a small core and many drivers.

Can we stop about the "bad light"? Back to the datacenter example,
pointing out that there's a single hard disk doesn't show a bad light
on the one that is there. It just points out that we should prepare
for the worse and add redundancy *before* the worse happens.

> Conversely, it will show that unmaintained subsystems where all the
> patches are going through akpm are working well.

Just like Thomas' metric will show that subsystems where a single
patch changing a printk or adding a comment would be the ideal
subsystem. This is just as good as any metric, and should be looked at
with some distance.

> > It's like running a datacenter off a single machine, with a single
> > power supply, a single internet connection and a single hard disk. No
> > one would want that.
> 
> Group maintainership is definitively good but you can't force people to
> get interested in a subsystem. and this is almost never an issue with
> the maintainer attitude that would be driving off contributors.

Again, you have a handful of first-hand experiences.

And true, you can't force people to be interested in a subsystem. And
implementing group maintainership will be hard for some subsystems
with a particular contribution pattern, just like yours.

But can't we at least acknowledge the issue and tend to fixing it when
we can?

Maxime

-- 
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com