korg/linux
0
0
Fork 0
mirror of https://mirrors.bfsu.edu.cn/git/linux.git synced 2024-12-04 01:24:12 +08:00
Code Issues Packages Projects Releases Wiki Activity

Documentation/maintainer-tip: Clarify merge window policy

Browse Source 
There are lots of maintainers "pings" during the merge window, even
for trivial patches.

Clarify that contributors should not expect progress on *any*
non-urgent patches during the merge window.  This applies to all
contributions, not just large ones.

Clarify the language around -rc1.  Trees really are closed during the
merge window.

Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Acked-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://lore.kernel.org/all/20240322183403.67BAEEFE%40davehans-spike.ostc.intel.com
This commit is contained in:
Dave Hansen 2024-03-22 11:34:03 -07:00
parent 39cd87c4eb
commit bdc42c8b9b
1 changed files with 9 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
Documentation/process/maintainer-tip.rst
View File

@ -409,20 +409,20 @@ See :ref:`resend_reminders`.
Merge window
^^^^^^^^^^^^
Please do not expect large patch series to be handled during the merge
window or even during the week before. Such patches should be submitted in
mergeable state *at* *least* a week before the merge window opens.
Exceptions are made for bug fixes and *sometimes* for small standalone
drivers for new hardware or minimally invasive patches for hardware
enablement.
Please do not expect patches to be reviewed or merged by tip
maintainers around or during the merge window. The trees are closed
to all but urgent fixes during this time. They reopen once the merge
window closes and a new -rc1 kernel has been released.
Large series should be submitted in mergeable state *at* *least* a week
before the merge window opens. Exceptions are made for bug fixes and
*sometimes* for small standalone drivers for new hardware or minimally
invasive patches for hardware enablement.
During the merge window, the maintainers instead focus on following the
upstream changes, fixing merge window fallout, collecting bug fixes, and
allowing themselves a breath. Please respect that.
The release candidate -rc1 is the starting point for new patches to be
applied which are targeted for the next merge window.
So called _urgent_ branches will be merged into mainline during the
stabilization phase of each release.