Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Bug-introducing patches

[Thomas Gleixner <tglx@linutronix.de>]

On Wed, 12 Sep 2018, Laurent Pinchart wrote:
> 
> Maintainers are much more than patch juggling monkeys, otherwise they could be 
> replaced by machines. I believe that maintainers are given the huge 
> responsibility of taking care of their community. Fostering a productive work 
> environment, attracting (and keeping) talented developers and reviewers is a 
> huge and honourable task, and gets my full respect. On top of that, if a 
> maintainer has great technical skills, it's even better, and I've learnt a lot 
> from talented maintainers over the time. I however believe that technical 
> skills are not an excuse for not leading by example and showing what the good 
> practices are by applying them.

I surely agree, but reality is different.

I definitely apply my own patches w/o a review tag from time to time. And
aside of obvious typo cleanups/fixlets, which really can and have to do
without, all of my patches are posted to LKML and I carefuly respect and
address review comments.

Though, what am I supposed to do if nothing happens? Repost them five times
to annoy people? Been there, tried that. Does not help.

Most of these patches are refactoring and cleanups of the subsystems I
maintain and I do them for three reasons:

  1) Making the code more maintainable, which in the first place serves the
     egoistic bastard I am, because it makes my life as a maintainer
     simpler in the long run. It also allows others to work easier on top
     of that, which again makes it easier for me to review.

  2) During review of a feature patch submitted by someone else, I notice
     that the code is crap already and the feature adds more crap to it.

     So I first try to nudge the submitter to fix that up, but either it's
     outside their expertise level or they are simply telling me: 'I need
     to get this in and cleanup is outside of the scope of my task'.

     For the latter, I just refuse to merge it most of the times, but then
     I already identified how it should be done and go back to #1

  3) New hardware, new levels of scale unearth shortcomings in the code. I
     get problem reports and because I deeply care about the stuff I'm
     responsible for, I go and fix it if nobody else cares. Guess what,
     often enough I do not even get a tested-by reply by the people who
     complained in the first place. But with the knowledge of the problem
     and the solution, I would be outright stupid to just put them into
     /dev/null because applying them again makes my life easier.

So again, it's a problem which has to do with the lack of review capacity
and the lack of people who really care beyond the brim of their teacup.

The 'Make feature X work upstream' task mentality of companies is part of
the problem along with the expectation, that maintainers will coach,
educate and babysit their newbies when they have been tasked with problems
way over their expertise levels. Especially the last part is frustrating
for everyone. The submitter has worked on this feature for a long time just
to get it shredded in pieces and then after I got frustrated by the review
ping pong, I give up and fix it myself in order to have time for other
things on that ever growing todo list.

This simply cannot scale at all and I'm well aware of it, but I completely
disagree that this can be fixed by more formalistic processes, gitlab or
whatever people dream up.

It has to be fixed at the mindset level. A code base as large and as
complex as the kernel needs continous refactoring and cannot be used as
dumping ground for new features in a drive by mode.

Aside of that, I see people working for large companies doing reviews in
their spare time, because they care about it. But that's just wrong, they
should be able to enjoy their spare time as anybody else and get the time
to review during their work hours.

I surely encourage people to review things and I offload quite some of the
work to people who care, but finding them and keeping them on board is hard
because their daily work just does not allow them to keep up.

I'm definitely open for new ideas and new ways to work, but OTOH I'm not
interested at all in the 'fix the symptoms' approach and thereby hoping
that the root cause will cure itself. It simply does not work independent
of the problem space.

Thanks,

	tglx