Scribd
Upload
12 views57 pages

Maintainer 1

The document discusses best practices for getting code patches accepted to the Linux kernel, including following coding styles and submission guidelines, thoroughly testing patches, and ensuring patches work as intended and don't break the build. It provides statistics on the size and number of contributors to the Linux kernel, and emphasizes maintaining high code quality to avoid frustrating kernel maintainers.

Uploaded by

유형곤
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
12 views57 pages

Maintainer 1

The document discusses best practices for getting code patches accepted to the Linux kernel, including following coding styles and submission guidelines, thoroughly testing patches, and ensuring patches work as intended and don't break the build. It provides statistics on the size and number of contributors to the Linux kernel, and emphasizes maintaining high code quality to avoid frustrating kernel maintainers.

Uploaded by

유형곤
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 57

Best Practices to Getting

Your Patches Accepted

Greg Kroah-Hartman
[email protected]
I don't want your code
or

Linux Kernel Maintainers,


why are they so grumpy?

Greg Kroah-Hartman
[email protected]
git.sr.ht/~gregkh/presentation-linux-maintainer
69,970 files
29,460,000 lines

Kernel release 5.9.0


4,659 developers
450+ companies

Kernel releases 5.4.0 – 5.9.0


September 2019 – October 2020
8,300 lines added
2,400 lines removed
2,100 lines modified

Kernel releases 5.4.0 – 5.9.0


September 2019 – October 2020
8,300 lines added
2,400 lines removed
2,100 lines modified
Every day
Kernel releases 5.4.0 – 5.9.0
September 2019 – October 2020
9.2 changes per hour

Kernel releases 5.4.0 – 5.9.0


September 2.6.20
2019 – October 2020
to 2.6.24-rc
10.8 changes per hour

5.8 release

2.6.20 to 2.6.24-rc
2.6.20 to 2.6.24-rc
Top developers by quantity
Chris Wilson 1377
Christoph Hellwig 1195
Mauro Carvalho Chehab 832
Takashi Iwai 740
Andy Shevchenko 739
YueHaibing 692
Colin Ian King 671
Geert Uytterhoeven 590
Masahiro Yamada 523
Gustavo Silva 567
Kernel releases 5.4.0 – 5.9.0
Top Signed-off-by:
David S. Miller 8446
Greg Kroah-Hartman 5028
Alex Deucher 4323
Mark Brown 3565
Mauro Carvalho Chehab 2596
Linus Torvalds 2446
Andrew Morton 2218
Chris Wilson 1884
Jens Axboe 1787
Martin Petersen 1639

Kernel releases 5.4.0 – 5.9.0


Who is funding this work?
1. “Amateurs” 13.5%
2. Intel 11.6%
3. Red Hat 6.6%
4. AMD 4.9%
5. Huawei 4.8%
6. Google 4.7%
7. Linaro 3.8%
8. SUSE 3.6%
9. IBM 3.1%
10. “Consultants” 2.7%
Kernel releases 5.4.0 – 5.9.0
Who is funding this work?
11. Mellanox 2.5%
12. NXP Semiconductors 2.2%
13. Renesas Electronics 2.2%
14. Facebook 2.0%
15. ARM 1.8%
16. Oracle 1.3%
17. Texas Instruments 1.2%
18. Code Aurora (Qualcomm) 1.2%
19. Linux Foundation 1.2%
20. Canonical 1.1%
Kernel releases 5.4.0 – 5.9.0
Kernel code Kernel code
submission accepted
“Working upstream
saves time and money”
Dan Frye – VP Open Systems, IBM
Dirk Hohndel – Chief Technologist, Intel

2.6.20 to 2.6.24-rc
Maintainers are like editors in
the publishing industry.
– David Miller

2.6.20 to 2.6.24-rc
Patches I received in a 2 week period

2.6.20 to 2.6.24-rc
Patches I received in a 2 week period

1487

2.6.20 to 2.6.24-rc
Subject: [PATCH 48/48] ...

2.6.20 to 2.6.24-rc
15 patch series, no order given

2.6.20 to 2.6.24-rc
Patches 1, 3-10

2.6.20 to 2.6.24-rc
“Signed-off-by:” in signature

2.6.20 to 2.6.24-rc
Signature saying email was confidential

2.6.20 to 2.6.24-rc
Tabs were converted to spaces

2.6.20 to 2.6.24-rc
Leading spaces removed

2.6.20 to 2.6.24-rc
diff in non-unified format

2.6.20 to 2.6.24-rc
Patch created in driver directory

2.6.20 to 2.6.24-rc
Patch created in /usr/src/linux-2.6.32

2.6.20 to 2.6.24-rc
Made against different tree

2.6.20 to 2.6.24-rc
Wrong coding style

2.6.20 to 2.6.24-rc
Wrong coding style,
and acknowledged it

2.6.20 to 2.6.24-rc
Would not compile

2.6.20 to 2.6.24-rc
Broke the build on patch 3/6

2.6.20 to 2.6.24-rc
Broke the build on patch 3/6
and fixed it on 6/6

2.6.20 to 2.6.24-rc
Broke the build on patch 5/8

2.6.20 to 2.6.24-rc
Broke the build on patch 5/8
Contained note that fix would be sent later

2.6.20 to 2.6.24-rc
Patches that had nothing to do with me

2.6.20 to 2.6.24-rc
1 patch, 450kb big (4500 lines added)

2.6.20 to 2.6.24-rc
Obviously wrong kerneldoc

2.6.20 to 2.6.24-rc
This was a calm two weeks

2.6.20 to 2.6.24-rc
How to do it right
Documentation/process/submitting-patches.rst
Documentation/process/submitting-drivers.rst
Documentation/process/submit-checklist.rst

2.6.20 to 2.6.24-rc
It is in my self-interest
to ignore your patch

2.6.20 to 2.6.24-rc
Give me no excuse
to reject your patch

2.6.20 to 2.6.24-rc
What I will do for you:

2.6.20 to 2.6.24-rc
Review your patch within 1-2 weeks

2.6.20 to 2.6.24-rc
Offer semi-constructive criticism

2.6.20 to 2.6.24-rc
Let you know the status of your patch

2.6.20 to 2.6.24-rc
<zx2c4> i think the reason it works is not neccessarily because
<zx2c4> the responses are so terrific
<zx2c4> but because
<zx2c4> they are TERRIFYING
<zx2c4> so i'm forced to do my best possible work

2.6.20 to 2.6.24-rc
git.sr.ht/~gregkh/presentation-linux-maintainer

photo CC by-ND 2.0 Antarctica Bound

You might also like