[Ksummit-discuss] "Maintainer summit" invitation discussion

Martin K. Petersen martin.petersen at oracle.com
Wed Apr 26 13:58:43 UTC 2017


> My patches are normally simple is probably part of the difference.

Patch complexity usually has something to do with it. In SCSI I deal
with simple patches right away. Other people are also willing to jump in
and review because the time commitment to do so is low.

It's much harder to get people to review intricate core changes because
they need a significant chunk of uninterrupted time. And that's a
precious resource.

Another gripe of mine wrt. big vs. small is that almost all vendor
driver updates come in the form of "30+ patches to update the driver to
version XYZ". Often a week before the merge window. And then they wonder
why nobody reviews them. Well, duh. That's a huge chunk of time for
somebody to commit.

It would be much better if they'd drop the arbitrary and pointless
"driver version XYZ" notion and just send a few patches per week.
Reviewers are much more inclined to go "Oh, I have 15 minutes now, let
me check my inbox". In most cases the reviews would also be more
thorough because you don't lose focus after patch number 7 and just
want this entire thing to be over before your brain turns into mush.

Anyway. Just being the devil's advocate here. It just seems there's a
consistent "maintainers are bad/lazy/unresponsive" theme going on. But
for better or for worse, patch submitters are often presenting their
work in ways that are completely indigestible. Not just to the
maintainers, but to the people willing to do reviews.

Not sure what we can do to address this? I often have big patch series
sitting tagged in my inbox for days/weeks while I chip away at them. But
the reality is that few, if any, reviewers do the same. If there is not
enough time to review a submission first time people see it in their
inbox, chances are that the review opportunity is lost forever.

And if nobody else reviews the patches the burden falls on me, making my
backlog even bigger.

Martin K. Petersen	Oracle Linux Engineering

More information about the Ksummit-discuss mailing list