The merge window is a period of time directly after a software release when many patches are merged. This allows patches a long time to be scrutinized and tested before the next release. During the merge window, which typically lasts two weeks for the Linux kernel, maintainers focus on quickly reviewing and merging new patches, while testing of the new patches occurs in the following release candidates period. Aligning development work with merge windows helps ensure patches are reviewed and integrated efficiently.

1. What is the
“merge window”?
Macpaul Lin
2021/11/12
macpaul <at> gmail.com
CC0

2. What is the “merge window”?
• According to Wikipedia
• https://en.wikipedia.org/wiki/Merge_window
• The merge window is a software development process which is
sometimes used by large projects.
• The merge window is a period of time that occurs directly
after the release of a new version of the software. During
this time, many patches are merged and hence have a long time
to get scrutinized and tested before the next release.
5.14 5.15-rc1 5.15-rc2 5.15-rc3 5.15-rc4 5.15-rc5 5.15-rc6 5.15-rc7 5.15 5.16-rc1
merge window merge window

3. What is the “merge window”?
• From Wikipedia
• The Linux kernel has used the merge window process since
July 2005 with the release of version 2.6.14. Since then,
every 2.6.*, 3.* and 4.* release has been followed by a
two-week merge window.[1]
• This causes much work for the project maintainers who
have to merge all the patches. The process may be split
up with people who inspect, approve and merge the patches.
• Ref
• https://www.kernel.org/doc/html/latest/process/2.Process.html?hig
hlight=merge%20window

4. What is the “merge window”?
• According to u-boot website
• https://www.denx.de/wiki/U-Boot/DevelopmentProcess
• The Merge Window is the period when new patches get
submitted (and hopefully accepted) for inclusion into U-
Boot mainline.
• This is the only time when new code (like support for new
processors or new boards, or other new features or
reorganization of code) is accepted.

5. Why merge window is important for
developing?
• Can’t we send new features everyday?
• Yes you can, but…
• Only during that period, maintainers will review patch quickly.
• Your patch will still be reviewed, but it won’t be applied to the
coming release tree.
• Once the patch has been accepted, it will be applied to “–next”
branch owned by subsystem maintainer.
• You will usually get short feedback latency during merge window.
• “-rcX” (release candidate) tags means QC (testing)!
• Everyone is doing QC after the merge window.
• Testing.
• Bug fixing.
• New bug fix will be applied to subsystem’s release tree.

6. Why merge window is important for
developing?
• The story
• Linux has bad old days before
• Build fail everyday, even fix build fail twice a day.
• Couldn’t start testing.
• https://web.archive.org/web/20120513035631/http://kerneltrap.org/
Linux/Active_Merge_Windows

7. Why merge window is important for
developing?
• People “do test” Linux during QC period before
release!
• Mainline Linux has its own CI.
• Build/merges tests.
• Booting tests.
• Subsystem function tests.
• Who will run these tests?
• Linux foundation.
• Maintainers.
• Contribute companies.

8. Merge window is for new ready
patch.
• Please send patch that you think it is ready to be
merged.
• These patches should be checked by checkpatch.pl and
other tools.
• Maintainers are busy at this moment.
• Patch will be accepted with higher chances during the
merge window.
• Because new feature cannot get high priority out of the merge
window.
• Maintainer will request more refactor out of the merge window.

9. What is the most important merge
window?
• Linux will release a LTS version every year.
• https://www.kernel.org/category/releases.html
• LTS means long-term support for stable versions.
• Who will use LTS kernel?
• Distros will prepare LTS/stable version based on LTS Linux kernel version.
• Google - Android will use LTS version for ACK developing.
• Other open-source projects – Yocto.
• LTS also means less maintain effort, especially security patches and
backport bug fixes.
• Everyone will focus on bug fix for LTS versions.
• LTS is usually come out during Oct~Dec.
• Everyone can have his own vacation after LTS is out. (just kidding)

10. How is merge/debugging ratio?
• Linux will be released every 2~3 months (8~12 weeks)
• The merge window is only 2 weeks.
• The ratio is 1:3~1:5 (25% merge, 75% debugging)

11. Release early,
Release often.
Open source development 101.

12. Release early, release often.
• Submit patch with basic function at the beginning.
• Split patch into small pieces.
• During the review,
• merge patches into a single large patch is easier.
• split will be slightly difficult and much manual work.
• No one can review a large bunch of changes in one time.
• Get feedback sooner for required changes
• Architecture, code placement, and from its logic to variable
typo.
• Each developer will gain experience when they submit
hand-on patches.

13. Case study
Stmmac Ethernet driver.
• Mail-Thread
• https://lkml.org/lkml/2021/11/12/133
• The same hardware IP for mt2712 and mt8195.
• Support mt2712 in mainline with some specific logics.
• Did’t support mt8195 before 5.16.
• Software task
• Abstract the common code.
• Add probe functions, compatible strings and new API hooks (parameters)
for mt8195.
• Improve document to full fill new kernel standards.
• Schedule
• 1 week for patches preparing (5 patches)
• Parameter and function confirmation with designers.
• 3 days for submit patches and reviewing. (Currently v3: 7 patches)

14. Case study
Stmmac Ethernet driver.
• Success reasons
• Based on previous work on mt2712.
• Upstream with landing on new platform.
• The driver author is positive to get new platform
upstream.
• RD’s manager support upstream task as a highest priority
request because of merge window is coming.

15. Case study
Improve performance for large data
transfer for usb-serial.
• Mail-thread
• https://lkml.org/lkml/2020/6/24/150
• Software task
• Just fix some hard coded values into definitions with
larger values.
• Fail reason (Maintainer’s reply)
• Since this can only be applied for the next merge window,
it would be much better if you work rework…

16. Resource allocation align each
merge window.
• Ideally, we should upstream the patch after press
release of a new platform/product.
• After internal QC done.
• After press release.
• After customer design-in and starting to ship the
platform to the market.
• But RD will get issues from customer after QC done,
and then, it comes the other new tasks for new
platform/product.

17. Resource allocation align each
merge window.
5.14 5.15-rc1 5.15-rc2 5.15-rc3 5.15-rc4 5.15-rc5 5.15-rc6 5.15-rc7 5.15 5.16-rc1
merge window merge window
Prepare patch
Allocate
resource
Bug fix
Test
and
debug
Refactor,
and
add new features.
Submit,
review,
and Revise!
Patch merged.
Life is
happy now.

18. Resource allocation align each
merge window.
• Why don’t you allocate resource align the merge
window?
• You’ll get 5~6 chances to submit new feature during a
year with higher efficiency.
• RD’s manager should help allocate resource for developer
“before” and “during” the merge window.
• Small and basic functions / refactor are welcome.
• Each merge window means a chance for refactoring the
legacy code and adopt to new kernel design.
• Reduce migration effort.
• Each line of code you submit, won’t be the tear next time when
you doing kernel migration (hopefully).

19. Q & A
Patch are welcome.
Fork are welcome.