1.. SPDX-License-Identifier: GPL-2.0 2 3The tip tree handbook 4===================== 5 6What is the tip tree? 7--------------------- 8 9The tip tree is a collection of several subsystems and areas of 10development. The tip tree is both a direct development tree and a 11aggregation tree for several sub-maintainer trees. The tip tree gitweb URL 12is: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 13 14The tip tree contains the following subsystems: 15 16 - **x86 architecture** 17 18 The x86 architecture development takes place in the tip tree except 19 for the x86 KVM and XEN specific parts which are maintained in the 20 corresponding subsystems and routed directly to mainline from 21 there. It's still good practice to Cc the x86 maintainers on 22 x86-specific KVM and XEN patches. 23 24 Some x86 subsystems have their own maintainers in addition to the 25 overall x86 maintainers. Please Cc the overall x86 maintainers on 26 patches touching files in arch/x86 even when they are not called out 27 by the MAINTAINER file. 28 29 Note, that ``x86@kernel.org`` is not a mailing list. It is merely a 30 mail alias which distributes mails to the x86 top-level maintainer 31 team. Please always Cc the Linux Kernel mailing list (LKML) 32 ``linux-kernel@vger.kernel.org``, otherwise your mail ends up only in 33 the private inboxes of the maintainers. 34 35 - **Scheduler** 36 37 Scheduler development takes place in the -tip tree, in the 38 sched/core branch - with occasional sub-topic trees for 39 work-in-progress patch-sets. 40 41 - **Locking and atomics** 42 43 Locking development (including atomics and other synchronization 44 primitives that are connected to locking) takes place in the -tip 45 tree, in the locking/core branch - with occasional sub-topic trees 46 for work-in-progress patch-sets. 47 48 - **Generic interrupt subsystem and interrupt chip drivers**: 49 50 - interrupt core development happens in the irq/core branch 51 52 - interrupt chip driver development also happens in the irq/core 53 branch, but the patches are usually applied in a separate maintainer 54 tree and then aggregated into irq/core 55 56 - **Time, timers, timekeeping, NOHZ and related chip drivers**: 57 58 - timekeeping, clocksource core, NTP and alarmtimer development 59 happens in the timers/core branch, but patches are usually applied in 60 a separate maintainer tree and then aggregated into timers/core 61 62 - clocksource/event driver development happens in the timers/core 63 branch, but patches are mostly applied in a separate maintainer tree 64 and then aggregated into timers/core 65 66 - **Performance counters core, architecture support and tooling**: 67 68 - perf core and architecture support development happens in the 69 perf/core branch 70 71 - perf tooling development happens in the perf tools maintainer 72 tree and is aggregated into the tip tree. 73 74 - **CPU hotplug core** 75 76 - **RAS core** 77 78 Mostly x86-specific RAS patches are collected in the tip ras/core 79 branch. 80 81 - **EFI core** 82 83 EFI development in the efi git tree. The collected patches are 84 aggregated in the tip efi/core branch. 85 86 - **RCU** 87 88 RCU development happens in the linux-rcu tree. The resulting changes 89 are aggregated into the tip core/rcu branch. 90 91 - **Various core code components**: 92 93 - debugobjects 94 95 - objtool 96 97 - random bits and pieces 98 99 100Patch submission notes 101---------------------- 102 103Selecting the tree/branch 104^^^^^^^^^^^^^^^^^^^^^^^^^ 105 106In general, development against the head of the tip tree master branch is 107fine, but for the subsystems which are maintained separately, have their 108own git tree and are only aggregated into the tip tree, development should 109take place against the relevant subsystem tree or branch. 110 111Bug fixes which target mainline should always be applicable against the 112mainline kernel tree. Potential conflicts against changes which are already 113queued in the tip tree are handled by the maintainers. 114 115Patch subject 116^^^^^^^^^^^^^ 117 118The tip tree preferred format for patch subject prefixes is 119'subsys/component:', e.g. 'x86/apic:', 'x86/mm/fault:', 'sched/fair:', 120'genirq/core:'. Please do not use file names or complete file paths as 121prefix. 'git log path/to/file' should give you a reasonable hint in most 122cases. 123 124The condensed patch description in the subject line should start with a 125uppercase letter and should be written in imperative tone. 126 127 128Changelog 129^^^^^^^^^ 130 131The general rules about changelogs in the process documentation, see 132:ref:`Documentation/process/ <submittingpatches>`, apply. 133 134The tip tree maintainers set value on following these rules, especially on 135the request to write changelogs in imperative mood and not impersonating 136code or the execution of it. This is not just a whim of the 137maintainers. Changelogs written in abstract words are more precise and 138tend to be less confusing than those written in the form of novels. 139 140It's also useful to structure the changelog into several paragraphs and not 141lump everything together into a single one. A good structure is to explain 142the context, the problem and the solution in separate paragraphs and this 143order. 144 145Examples for illustration: 146 147 Example 1:: 148 149 x86/intel_rdt/mbm: Fix MBM overflow handler during hot cpu 150 151 When a CPU is dying, we cancel the worker and schedule a new worker on a 152 different CPU on the same domain. But if the timer is already about to 153 expire (say 0.99s) then we essentially double the interval. 154 155 We modify the hot cpu handling to cancel the delayed work on the dying 156 cpu and run the worker immediately on a different cpu in same domain. We 157 donot flush the worker because the MBM overflow worker reschedules the 158 worker on same CPU and scans the domain->cpu_mask to get the domain 159 pointer. 160 161 Improved version:: 162 163 x86/intel_rdt/mbm: Fix MBM overflow handler during CPU hotplug 164 165 When a CPU is dying, the overflow worker is canceled and rescheduled on a 166 different CPU in the same domain. But if the timer is already about to 167 expire this essentially doubles the interval which might result in a non 168 detected overflow. 169 170 Cancel the overflow worker and reschedule it immediately on a different CPU 171 in the same domain. The work could be flushed as well, but that would 172 reschedule it on the same CPU. 173 174 Example 2:: 175 176 time: POSIX CPU timers: Ensure that variable is initialized 177 178 If cpu_timer_sample_group returns -EINVAL, it will not have written into 179 *sample. Checking for cpu_timer_sample_group's return value precludes the 180 potential use of an uninitialized value of now in the following block. 181 Given an invalid clock_idx, the previous code could otherwise overwrite 182 *oldval in an undefined manner. This is now prevented. We also exploit 183 short-circuiting of && to sample the timer only if the result will 184 actually be used to update *oldval. 185 186 Improved version:: 187 188 posix-cpu-timers: Make set_process_cpu_timer() more robust 189 190 Because the return value of cpu_timer_sample_group() is not checked, 191 compilers and static checkers can legitimately warn about a potential use 192 of the uninitialized variable 'now'. This is not a runtime issue as all 193 call sites hand in valid clock ids. 194 195 Also cpu_timer_sample_group() is invoked unconditionally even when the 196 result is not used because *oldval is NULL. 197 198 Make the invocation conditional and check the return value. 199 200 Example 3:: 201 202 The entity can also be used for other purposes. 203 204 Let's rename it to be more generic. 205 206 Improved version:: 207 208 The entity can also be used for other purposes. 209 210 Rename it to be more generic. 211 212 213For complex scenarios, especially race conditions and memory ordering 214issues, it is valuable to depict the scenario with a table which shows 215the parallelism and the temporal order of events. Here is an example:: 216 217 CPU0 CPU1 218 free_irq(X) interrupt X 219 spin_lock(desc->lock) 220 wake irq thread() 221 spin_unlock(desc->lock) 222 spin_lock(desc->lock) 223 remove action() 224 shutdown_irq() 225 release_resources() thread_handler() 226 spin_unlock(desc->lock) access released resources. 227 ^^^^^^^^^^^^^^^^^^^^^^^^^ 228 synchronize_irq() 229 230Lockdep provides similar useful output to depict a possible deadlock 231scenario:: 232 233 CPU0 CPU1 234 rtmutex_lock(&rcu->rt_mutex) 235 spin_lock(&rcu->rt_mutex.wait_lock) 236 local_irq_disable() 237 spin_lock(&timer->it_lock) 238 spin_lock(&rcu->mutex.wait_lock) 239 --> Interrupt 240 spin_lock(&timer->it_lock) 241 242 243Function references in changelogs 244^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 245 246When a function is mentioned in the changelog, either the text body or the 247subject line, please use the format 'function_name()'. Omitting the 248brackets after the function name can be ambiguous:: 249 250 Subject: subsys/component: Make reservation_count static 251 252 reservation_count is only used in reservation_stats. Make it static. 253 254The variant with brackets is more precise:: 255 256 Subject: subsys/component: Make reservation_count() static 257 258 reservation_count() is only called from reservation_stats(). Make it 259 static. 260 261 262Backtraces in changelogs 263^^^^^^^^^^^^^^^^^^^^^^^^ 264 265See :ref:`backtraces`. 266 267Ordering of commit tags 268^^^^^^^^^^^^^^^^^^^^^^^ 269 270To have a uniform view of the commit tags, the tip maintainers use the 271following tag ordering scheme: 272 273 - Fixes: 12char-SHA1 ("sub/sys: Original subject line") 274 275 A Fixes tag should be added even for changes which do not need to be 276 backported to stable kernels, i.e. when addressing a recently introduced 277 issue which only affects tip or the current head of mainline. These tags 278 are helpful to identify the original commit and are much more valuable 279 than prominently mentioning the commit which introduced a problem in the 280 text of the changelog itself because they can be automatically 281 extracted. 282 283 The following example illustrates the difference:: 284 285 Commit 286 287 abcdef012345678 ("x86/xxx: Replace foo with bar") 288 289 left an unused instance of variable foo around. Remove it. 290 291 Signed-off-by: J.Dev <j.dev@mail> 292 293 Please say instead:: 294 295 The recent replacement of foo with bar left an unused instance of 296 variable foo around. Remove it. 297 298 Fixes: abcdef012345678 ("x86/xxx: Replace foo with bar") 299 Signed-off-by: J.Dev <j.dev@mail> 300 301 The latter puts the information about the patch into the focus and 302 amends it with the reference to the commit which introduced the issue 303 rather than putting the focus on the original commit in the first place. 304 305 - Reported-by: ``Reporter <reporter@mail>`` 306 307 - Originally-by: ``Original author <original-author@mail>`` 308 309 - Suggested-by: ``Suggester <suggester@mail>`` 310 311 - Co-developed-by: ``Co-author <co-author@mail>`` 312 313 Signed-off: ``Co-author <co-author@mail>`` 314 315 Note, that Co-developed-by and Signed-off-by of the co-author(s) must 316 come in pairs. 317 318 - Signed-off-by: ``Author <author@mail>`` 319 320 The first Signed-off-by (SOB) after the last Co-developed-by/SOB pair is the 321 author SOB, i.e. the person flagged as author by git. 322 323 - Signed-off-by: ``Patch handler <handler@mail>`` 324 325 SOBs after the author SOB are from people handling and transporting 326 the patch, but were not involved in development. SOB chains should 327 reflect the **real** route a patch took as it was propagated to us, 328 with the first SOB entry signalling primary authorship of a single 329 author. Acks should be given as Acked-by lines and review approvals 330 as Reviewed-by lines. 331 332 If the handler made modifications to the patch or the changelog, then 333 this should be mentioned **after** the changelog text and **above** 334 all commit tags in the following format:: 335 336 ... changelog text ends. 337 338 [ handler: Replaced foo by bar and updated changelog ] 339 340 First-tag: ..... 341 342 Note the two empty new lines which separate the changelog text and the 343 commit tags from that notice. 344 345 If a patch is sent to the mailing list by a handler then the author has 346 to be noted in the first line of the changelog with:: 347 348 From: Author <author@mail> 349 350 Changelog text starts here.... 351 352 so the authorship is preserved. The 'From:' line has to be followed 353 by a empty newline. If that 'From:' line is missing, then the patch 354 would be attributed to the person who sent (transported, handled) it. 355 The 'From:' line is automatically removed when the patch is applied 356 and does not show up in the final git changelog. It merely affects 357 the authorship information of the resulting Git commit. 358 359 - Tested-by: ``Tester <tester@mail>`` 360 361 - Reviewed-by: ``Reviewer <reviewer@mail>`` 362 363 - Acked-by: ``Acker <acker@mail>`` 364 365 - Cc: ``cc-ed-person <person@mail>`` 366 367 If the patch should be backported to stable, then please add a '``Cc: 368 stable@vger.kernel.org``' tag, but do not Cc stable when sending your 369 mail. 370 371 - Link: ``https://link/to/information`` 372 373 For referring to an email on LKML or other kernel mailing lists, 374 please use the lore.kernel.org redirector URL:: 375 376 https://lore.kernel.org/r/email-message@id 377 378 The kernel.org redirector is considered a stable URL, unlike other email 379 archives. 380 381 Maintainers will add a Link tag referencing the email of the patch 382 submission when they apply a patch to the tip tree. This tag is useful 383 for later reference and is also used for commit notifications. 384 385Please do not use combined tags, e.g. ``Reported-and-tested-by``, as 386they just complicate automated extraction of tags. 387 388 389Links to documentation 390^^^^^^^^^^^^^^^^^^^^^^ 391 392Providing links to documentation in the changelog is a great help to later 393debugging and analysis. Unfortunately, URLs often break very quickly 394because companies restructure their websites frequently. Non-'volatile' 395exceptions include the Intel SDM and the AMD APM. 396 397Therefore, for 'volatile' documents, please create an entry in the kernel 398bugzilla https://bugzilla.kernel.org and attach a copy of these documents 399to the bugzilla entry. Finally, provide the URL of the bugzilla entry in 400the changelog. 401 402Patch resend or reminders 403^^^^^^^^^^^^^^^^^^^^^^^^^ 404 405See :ref:`resend_reminders`. 406 407Merge window 408^^^^^^^^^^^^ 409 410Please do not expect large patch series to be handled during the merge 411window or even during the week before. Such patches should be submitted in 412mergeable state *at* *least* a week before the merge window opens. 413Exceptions are made for bug fixes and *sometimes* for small standalone 414drivers for new hardware or minimally invasive patches for hardware 415enablement. 416 417During the merge window, the maintainers instead focus on following the 418upstream changes, fixing merge window fallout, collecting bug fixes, and 419allowing themselves a breath. Please respect that. 420 421The release candidate -rc1 is the starting point for new patches to be 422applied which are targeted for the next merge window. 423 424 425Git 426^^^ 427 428The tip maintainers accept git pull requests from maintainers who provide 429subsystem changes for aggregation in the tip tree. 430 431Pull requests for new patch submissions are usually not accepted and do not 432replace proper patch submission to the mailing list. The main reason for 433this is that the review workflow is email based. 434 435If you submit a larger patch series it is helpful to provide a git branch 436in a private repository which allows interested people to easily pull the 437series for testing. The usual way to offer this is a git URL in the cover 438letter of the patch series. 439 440Testing 441^^^^^^^ 442 443Code should be tested before submitting to the tip maintainers. Anything 444other than minor changes should be built, booted and tested with 445comprehensive (and heavyweight) kernel debugging options enabled. 446 447These debugging options can be found in kernel/configs/x86_debug.config 448and can be added to an existing kernel config by running: 449 450 make x86_debug.config 451 452Some of these options are x86-specific and can be left out when testing 453on other architectures. 454 455Coding style notes 456------------------ 457 458Comment style 459^^^^^^^^^^^^^ 460 461Sentences in comments start with an uppercase letter. 462 463Single line comments:: 464 465 /* This is a single line comment */ 466 467Multi-line comments:: 468 469 /* 470 * This is a properly formatted 471 * multi-line comment. 472 * 473 * Larger multi-line comments should be split into paragraphs. 474 */ 475 476No tail comments: 477 478 Please refrain from using tail comments. Tail comments disturb the 479 reading flow in almost all contexts, but especially in code:: 480 481 if (somecondition_is_true) /* Don't put a comment here */ 482 dostuff(); /* Neither here */ 483 484 seed = MAGIC_CONSTANT; /* Nor here */ 485 486 Use freestanding comments instead:: 487 488 /* This condition is not obvious without a comment */ 489 if (somecondition_is_true) { 490 /* This really needs to be documented */ 491 dostuff(); 492 } 493 494 /* This magic initialization needs a comment. Maybe not? */ 495 seed = MAGIC_CONSTANT; 496 497Comment the important things: 498 499 Comments should be added where the operation is not obvious. Documenting 500 the obvious is just a distraction:: 501 502 /* Decrement refcount and check for zero */ 503 if (refcount_dec_and_test(&p->refcnt)) { 504 do; 505 lots; 506 of; 507 magic; 508 things; 509 } 510 511 Instead, comments should explain the non-obvious details and document 512 constraints:: 513 514 if (refcount_dec_and_test(&p->refcnt)) { 515 /* 516 * Really good explanation why the magic things below 517 * need to be done, ordering and locking constraints, 518 * etc.. 519 */ 520 do; 521 lots; 522 of; 523 magic; 524 /* Needs to be the last operation because ... */ 525 things; 526 } 527 528Function documentation comments: 529 530 To document functions and their arguments please use kernel-doc format 531 and not free form comments:: 532 533 /** 534 * magic_function - Do lots of magic stuff 535 * @magic: Pointer to the magic data to operate on 536 * @offset: Offset in the data array of @magic 537 * 538 * Deep explanation of mysterious things done with @magic along 539 * with documentation of the return values. 540 * 541 * Note, that the argument descriptors above are arranged 542 * in a tabular fashion. 543 */ 544 545 This applies especially to globally visible functions and inline 546 functions in public header files. It might be overkill to use kernel-doc 547 format for every (static) function which needs a tiny explanation. The 548 usage of descriptive function names often replaces these tiny comments. 549 Apply common sense as always. 550 551 552Documenting locking requirements 553^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 554 Documenting locking requirements is a good thing, but comments are not 555 necessarily the best choice. Instead of writing:: 556 557 /* Caller must hold foo->lock */ 558 void func(struct foo *foo) 559 { 560 ... 561 } 562 563 Please use:: 564 565 void func(struct foo *foo) 566 { 567 lockdep_assert_held(&foo->lock); 568 ... 569 } 570 571 In PROVE_LOCKING kernels, lockdep_assert_held() emits a warning 572 if the caller doesn't hold the lock. Comments can't do that. 573 574Bracket rules 575^^^^^^^^^^^^^ 576 577Brackets should be omitted only if the statement which follows 'if', 'for', 578'while' etc. is truly a single line:: 579 580 if (foo) 581 do_something(); 582 583The following is not considered to be a single line statement even 584though C does not require brackets:: 585 586 for (i = 0; i < end; i++) 587 if (foo[i]) 588 do_something(foo[i]); 589 590Adding brackets around the outer loop enhances the reading flow:: 591 592 for (i = 0; i < end; i++) { 593 if (foo[i]) 594 do_something(foo[i]); 595 } 596 597 598Variable declarations 599^^^^^^^^^^^^^^^^^^^^^ 600 601The preferred ordering of variable declarations at the beginning of a 602function is reverse fir tree order:: 603 604 struct long_struct_name *descriptive_name; 605 unsigned long foo, bar; 606 unsigned int tmp; 607 int ret; 608 609The above is faster to parse than the reverse ordering:: 610 611 int ret; 612 unsigned int tmp; 613 unsigned long foo, bar; 614 struct long_struct_name *descriptive_name; 615 616And even more so than random ordering:: 617 618 unsigned long foo, bar; 619 int ret; 620 struct long_struct_name *descriptive_name; 621 unsigned int tmp; 622 623Also please try to aggregate variables of the same type into a single 624line. There is no point in wasting screen space:: 625 626 unsigned long a; 627 unsigned long b; 628 unsigned long c; 629 unsigned long d; 630 631It's really sufficient to do:: 632 633 unsigned long a, b, c, d; 634 635Please also refrain from introducing line splits in variable declarations:: 636 637 struct long_struct_name *descriptive_name = container_of(bar, 638 struct long_struct_name, 639 member); 640 struct foobar foo; 641 642It's way better to move the initialization to a separate line after the 643declarations:: 644 645 struct long_struct_name *descriptive_name; 646 struct foobar foo; 647 648 descriptive_name = container_of(bar, struct long_struct_name, member); 649 650 651Variable types 652^^^^^^^^^^^^^^ 653 654Please use the proper u8, u16, u32, u64 types for variables which are meant 655to describe hardware or are used as arguments for functions which access 656hardware. These types are clearly defining the bit width and avoid 657truncation, expansion and 32/64-bit confusion. 658 659u64 is also recommended in code which would become ambiguous for 32-bit 660kernels when 'unsigned long' would be used instead. While in such 661situations 'unsigned long long' could be used as well, u64 is shorter 662and also clearly shows that the operation is required to be 64 bits wide 663independent of the target CPU. 664 665Please use 'unsigned int' instead of 'unsigned'. 666 667 668Constants 669^^^^^^^^^ 670 671Please do not use literal (hexa)decimal numbers in code or initializers. 672Either use proper defines which have descriptive names or consider using 673an enum. 674 675 676Struct declarations and initializers 677^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 678 679Struct declarations should align the struct member names in a tabular 680fashion:: 681 682 struct bar_order { 683 unsigned int guest_id; 684 int ordered_item; 685 struct menu *menu; 686 }; 687 688Please avoid documenting struct members within the declaration, because 689this often results in strangely formatted comments and the struct members 690become obfuscated:: 691 692 struct bar_order { 693 unsigned int guest_id; /* Unique guest id */ 694 int ordered_item; 695 /* Pointer to a menu instance which contains all the drinks */ 696 struct menu *menu; 697 }; 698 699Instead, please consider using the kernel-doc format in a comment preceding 700the struct declaration, which is easier to read and has the added advantage 701of including the information in the kernel documentation, for example, as 702follows:: 703 704 705 /** 706 * struct bar_order - Description of a bar order 707 * @guest_id: Unique guest id 708 * @ordered_item: The item number from the menu 709 * @menu: Pointer to the menu from which the item 710 * was ordered 711 * 712 * Supplementary information for using the struct. 713 * 714 * Note, that the struct member descriptors above are arranged 715 * in a tabular fashion. 716 */ 717 struct bar_order { 718 unsigned int guest_id; 719 int ordered_item; 720 struct menu *menu; 721 }; 722 723Static struct initializers must use C99 initializers and should also be 724aligned in a tabular fashion:: 725 726 static struct foo statfoo = { 727 .a = 0, 728 .plain_integer = CONSTANT_DEFINE_OR_ENUM, 729 .bar = &statbar, 730 }; 731 732Note that while C99 syntax allows the omission of the final comma, 733we recommend the use of a comma on the last line because it makes 734reordering and addition of new lines easier, and makes such future 735patches slightly easier to read as well. 736 737Line breaks 738^^^^^^^^^^^ 739 740Restricting line length to 80 characters makes deeply indented code hard to 741read. Consider breaking out code into helper functions to avoid excessive 742line breaking. 743 744The 80 character rule is not a strict rule, so please use common sense when 745breaking lines. Especially format strings should never be broken up. 746 747When splitting function declarations or function calls, then please align 748the first argument in the second line with the first argument in the first 749line:: 750 751 static int long_function_name(struct foobar *barfoo, unsigned int id, 752 unsigned int offset) 753 { 754 755 if (!id) { 756 ret = longer_function_name(barfoo, DEFAULT_BARFOO_ID, 757 offset); 758 ... 759 760Namespaces 761^^^^^^^^^^ 762 763Function/variable namespaces improve readability and allow easy 764grepping. These namespaces are string prefixes for globally visible 765function and variable names, including inlines. These prefixes should 766combine the subsystem and the component name such as 'x86_comp\_', 767'sched\_', 'irq\_', and 'mutex\_'. 768 769This also includes static file scope functions that are immediately put 770into globally visible driver templates - it's useful for those symbols 771to carry a good prefix as well, for backtrace readability. 772 773Namespace prefixes may be omitted for local static functions and 774variables. Truly local functions, only called by other local functions, 775can have shorter descriptive names - our primary concern is greppability 776and backtrace readability. 777 778Please note that 'xxx_vendor\_' and 'vendor_xxx_` prefixes are not 779helpful for static functions in vendor-specific files. After all, it 780is already clear that the code is vendor-specific. In addition, vendor 781names should only be for truly vendor-specific functionality. 782 783As always apply common sense and aim for consistency and readability. 784 785 786Commit notifications 787-------------------- 788 789The tip tree is monitored by a bot for new commits. The bot sends an email 790for each new commit to a dedicated mailing list 791(``linux-tip-commits@vger.kernel.org``) and Cc's all people who are 792mentioned in one of the commit tags. It uses the email message ID from the 793Link tag at the end of the tag list to set the In-Reply-To email header so 794the message is properly threaded with the patch submission email. 795 796The tip maintainers and submaintainers try to reply to the submitter 797when merging a patch, but they sometimes forget or it does not fit the 798workflow of the moment. While the bot message is purely mechanical, it 799also implies a 'Thank you! Applied.'. 800