On Tue, Apr 13, 2021 at 03:02:21PM -0600, Jonathan Corbet wrote:
> For future installments, could you send them in their own thread as an
> ordinary patch so I don't need to edit in the changelog after applying
> them?
Ok, sure but I might not need to anymore because, AFAICT, what is left
is really tip-tree specific and that can finally be the tip-tree doc
file.
I'm pasting the whole thing below, if you think something's still
generic enough, lemme know and I'll carve it out.
Thx.
---
.. SPDX-License-Identifier: GPL-2.0
The tip tree handbook
=
What is the tip tree?
-
The tip tree is a collection of several subsystems and areas of
development. The tip tree is both a direct development tree and a
aggregation tree for several sub-maintainer trees. The tip tree gitweb URL
is: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
The tip tree contains the following subsystems:
- **x86 architecture**
The x86 architecture development takes place in the tip tree except
for the x86 KVM and XEN specific parts which are maintained in the
corresponding subsystems and routed directly to mainline from
there. It's still good practice to Cc the x86 maintainers on
x86-specific KVM and XEN patches.
Some x86 subsystems have their own maintainers in addition to the
overall x86 maintainers. Please Cc the overall x86 maintainers on
patches touching files in arch/x86 even when they are not called out
by the MAINTAINER file.
Note, that ``x...@kernel.org`` is not a mailing list. It is merely a
mail alias which distributes mails to the x86 top-level maintainer
team. Please always Cc the Linux Kernel mailing list (LKML)
``linux-kernel@vger.kernel.org``, otherwise your mail ends up only in
the private inboxes of the maintainers.
- **Scheduler**
Scheduler development takes place in the -tip tree, in the
sched/core branch - with occasional sub-topic trees for
work-in-progress patch-sets.
- **Locking and atomics**
Locking development (including atomics and other synchronization
primitives that are connected to locking) takes place in the -tip
tree, in the locking/core branch - with occasional sub-topic trees
for work-in-progress patch-sets.
- **Generic interrupt subsystem and interrupt chip drivers**:
- interrupt core development happens in the irq/core branch
- interrupt chip driver development also happens in the irq/core
branch, but the patches are usually applied in a separate maintainer
tree and then aggregated into irq/core
- **Time, timers, timekeeping, NOHZ and related chip drivers**:
- timekeeping, clocksource core, NTP and alarmtimer development
happens in the timers/core branch, but patches are usually applied in
a separate maintainer tree and then aggregated into timers/core
- clocksource/event driver development happens in the timers/core
branch, but patches are mostly applied in a separate maintainer tree
and then aggregated into timers/core
- **Performance counters core, architecture support and tooling**:
- perf core and architecture support development happens in the
perf/core branch
- perf tooling development happens in the perf tools maintainer
tree and is aggregated into the tip tree.
- **CPU hotplug core**
- **RAS core**
- **EFI core**
EFI development in the efi git tree. The collected patches are
aggregated in the tip efi/core branch.
- **RCU**
RCU development happens in the linux-rcu tree. The resulting changes
are aggregated into the tip core/rcu branch.
- **Various core code components**:
- debugobjects
- objtool
- random bits and pieces
Patch submission notes
--
Selecting the tree/branch
^
In general, development against the head of the tip tree master branch is
fine, but for the subsystems which are maintained separately, have their
own git tree and are only aggregated into the tip tree, development should
take place against the relevant subsystem tree or branch.
Bug fixes which target mainline should always be applicable against the
mainline kernel tree. Potential conflicts against changes which are already
queued in the tip tree are handled by the maintainers.
Patch subject
^
The tip tree preferred format for patch subject prefixes is
'subsys/component:', e.g. 'x86/apic:', 'x86/mm/fault:', 'sched/fair:',
'genirq/core:'. Please do not use file names or complete file paths as
prefix. 'git log path/to/file' should give you a reasonable hint in most
cases.
The condensed patch description in the subject line should start with a
uppercase letter and should be written in imperative tone.
Changelog
^
The general rules about changelogs in the process documentation, see
:ref:`Documentation/process/ `,
