849 lines · plain
1.. SPDX-License-Identifier: GPL-2.02 3The tip tree handbook4=====================5 6What is the tip tree?7---------------------8 9The tip tree is a collection of several subsystems and areas of10development. The tip tree is both a direct development tree and a11aggregation tree for several sub-maintainer trees. The tip tree gitweb URL12is: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git13 14The tip tree contains the following subsystems:15 16 - **x86 architecture**17 18 The x86 architecture development takes place in the tip tree except19 for the x86 KVM and XEN specific parts which are maintained in the20 corresponding subsystems and routed directly to mainline from21 there. It's still good practice to Cc the x86 maintainers on22 x86-specific KVM and XEN patches.23 24 Some x86 subsystems have their own maintainers in addition to the25 overall x86 maintainers. Please Cc the overall x86 maintainers on26 patches touching files in arch/x86 even when they are not called out27 by the MAINTAINER file.28 29 Note, that ``x86@kernel.org`` is not a mailing list. It is merely a30 mail alias which distributes mails to the x86 top-level maintainer31 team. Please always Cc the Linux Kernel mailing list (LKML)32 ``linux-kernel@vger.kernel.org``, otherwise your mail ends up only in33 the private inboxes of the maintainers.34 35 - **Scheduler**36 37 Scheduler development takes place in the -tip tree, in the38 sched/core branch - with occasional sub-topic trees for39 work-in-progress patch-sets.40 41 - **Locking and atomics**42 43 Locking development (including atomics and other synchronization44 primitives that are connected to locking) takes place in the -tip45 tree, in the locking/core branch - with occasional sub-topic trees46 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 branch51 52 - interrupt chip driver development also happens in the irq/core53 branch, but the patches are usually applied in a separate maintainer54 tree and then aggregated into irq/core55 56 - **Time, timers, timekeeping, NOHZ and related chip drivers**:57 58 - timekeeping, clocksource core, NTP and alarmtimer development59 happens in the timers/core branch, but patches are usually applied in60 a separate maintainer tree and then aggregated into timers/core61 62 - clocksource/event driver development happens in the timers/core63 branch, but patches are mostly applied in a separate maintainer tree64 and then aggregated into timers/core65 66 - **Performance counters core, architecture support and tooling**:67 68 - perf core and architecture support development happens in the69 perf/core branch70 71 - perf tooling development happens in the perf tools maintainer72 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/core79 branch.80 81 - **EFI core**82 83 EFI development in the efi git tree. The collected patches are84 aggregated in the tip efi/core branch.85 86 - **RCU**87 88 RCU development happens in the linux-rcu tree. The resulting changes89 are aggregated into the tip core/rcu branch.90 91 - **Various core code components**:92 93 - debugobjects94 95 - objtool96 97 - random bits and pieces98 99 100Patch submission notes101----------------------102 103Selecting the tree/branch104^^^^^^^^^^^^^^^^^^^^^^^^^105 106In general, development against the head of the tip tree master branch is107fine, but for the subsystems which are maintained separately, have their108own git tree and are only aggregated into the tip tree, development should109take place against the relevant subsystem tree or branch.110 111Bug fixes which target mainline should always be applicable against the112mainline kernel tree. Potential conflicts against changes which are already113queued in the tip tree are handled by the maintainers.114 115Patch subject116^^^^^^^^^^^^^117 118The tip tree preferred format for patch subject prefixes is119'subsys/component:', e.g. 'x86/apic:', 'x86/mm/fault:', 'sched/fair:',120'genirq/core:'. Please do not use file names or complete file paths as121prefix. 'git log path/to/file' should give you a reasonable hint in most122cases.123 124The condensed patch description in the subject line should start with a125uppercase letter and should be written in imperative tone.126 127 128Changelog129^^^^^^^^^130 131The general rules about changelogs in the :ref:`Submitting patches guide132<describe_changes>`, apply.133 134The tip tree maintainers set value on following these rules, especially on135the request to write changelogs in imperative mood and not impersonating136code or the execution of it. This is not just a whim of the137maintainers. Changelogs written in abstract words are more precise and138tend 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 not141lump everything together into a single one. A good structure is to explain142the context, the problem and the solution in separate paragraphs and this143order.144 145Examples for illustration:146 147 Example 1::148 149 x86/intel_rdt/mbm: Fix MBM overflow handler during hot cpu150 151 When a CPU is dying, we cancel the worker and schedule a new worker on a152 different CPU on the same domain. But if the timer is already about to153 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 dying156 cpu and run the worker immediately on a different cpu in same domain. We157 do not flush the worker because the MBM overflow worker reschedules the158 worker on same CPU and scans the domain->cpu_mask to get the domain159 pointer.160 161 Improved version::162 163 x86/intel_rdt/mbm: Fix MBM overflow handler during CPU hotplug164 165 When a CPU is dying, the overflow worker is canceled and rescheduled on a166 different CPU in the same domain. But if the timer is already about to167 expire this essentially doubles the interval which might result in a non168 detected overflow.169 170 Cancel the overflow worker and reschedule it immediately on a different CPU171 in the same domain. The work could be flushed as well, but that would172 reschedule it on the same CPU.173 174 Example 2::175 176 time: POSIX CPU timers: Ensure that variable is initialized177 178 If cpu_timer_sample_group returns -EINVAL, it will not have written into179 *sample. Checking for cpu_timer_sample_group's return value precludes the180 potential use of an uninitialized value of now in the following block.181 Given an invalid clock_idx, the previous code could otherwise overwrite182 *oldval in an undefined manner. This is now prevented. We also exploit183 short-circuiting of && to sample the timer only if the result will184 actually be used to update *oldval.185 186 Improved version::187 188 posix-cpu-timers: Make set_process_cpu_timer() more robust189 190 Because the return value of cpu_timer_sample_group() is not checked,191 compilers and static checkers can legitimately warn about a potential use192 of the uninitialized variable 'now'. This is not a runtime issue as all193 call sites hand in valid clock ids.194 195 Also cpu_timer_sample_group() is invoked unconditionally even when the196 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 ordering214issues, it is valuable to depict the scenario with a table which shows215the parallelism and the temporal order of events. Here is an example::216 217 CPU0 CPU1218 free_irq(X) interrupt X219 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 deadlock231scenario::232 233 CPU0 CPU1234 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 --> Interrupt240 spin_lock(&timer->it_lock)241 242 243Function references in changelogs244^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^245 246When a function is mentioned in the changelog, either the text body or the247subject line, please use the format 'function_name()'. Omitting the248brackets after the function name can be ambiguous::249 250 Subject: subsys/component: Make reservation_count static251 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() static257 258 reservation_count() is only called from reservation_stats(). Make it259 static.260 261 262Backtraces in changelogs263^^^^^^^^^^^^^^^^^^^^^^^^264 265See :ref:`backtraces`.266 267Ordering of commit tags268^^^^^^^^^^^^^^^^^^^^^^^269 270To have a uniform view of the commit tags, the tip maintainers use the271following 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 be276 backported to stable kernels, i.e. when addressing a recently introduced277 issue which only affects tip or the current head of mainline. These tags278 are helpful to identify the original commit and are much more valuable279 than prominently mentioning the commit which introduced a problem in the280 text of the changelog itself because they can be automatically281 extracted.282 283 The following example illustrates the difference::284 285 Commit286 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 of296 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 and302 amends it with the reference to the commit which introduced the issue303 rather than putting the focus on the original commit in the first place.304 305 - Reported-by: ``Reporter <reporter@mail>``306 307 - Closes: ``URL or Message-ID of the bug report this is fixing``308 309 - Originally-by: ``Original author <original-author@mail>``310 311 - Suggested-by: ``Suggester <suggester@mail>``312 313 - Co-developed-by: ``Co-author <co-author@mail>``314 315 Signed-off-by: ``Co-author <co-author@mail>``316 317 Note, that Co-developed-by and Signed-off-by of the co-author(s) must318 come in pairs.319 320 - Signed-off-by: ``Author <author@mail>``321 322 The first Signed-off-by (SOB) after the last Co-developed-by/SOB pair is the323 author SOB, i.e. the person flagged as author by git.324 325 - Signed-off-by: ``Patch handler <handler@mail>``326 327 SOBs after the author SOB are from people handling and transporting328 the patch, but were not involved in development. SOB chains should329 reflect the **real** route a patch took as it was propagated to us,330 with the first SOB entry signalling primary authorship of a single331 author. Acks should be given as Acked-by lines and review approvals332 as Reviewed-by lines.333 334 If the handler made modifications to the patch or the changelog, then335 this should be mentioned **after** the changelog text and **above**336 all commit tags in the following format::337 338 ... changelog text ends.339 340 [ handler: Replaced foo by bar and updated changelog ]341 342 First-tag: .....343 344 Note the two empty new lines which separate the changelog text and the345 commit tags from that notice.346 347 If a patch is sent to the mailing list by a handler then the author has348 to be noted in the first line of the changelog with::349 350 From: Author <author@mail>351 352 Changelog text starts here....353 354 so the authorship is preserved. The 'From:' line has to be followed355 by a empty newline. If that 'From:' line is missing, then the patch356 would be attributed to the person who sent (transported, handled) it.357 The 'From:' line is automatically removed when the patch is applied358 and does not show up in the final git changelog. It merely affects359 the authorship information of the resulting Git commit.360 361 - Tested-by: ``Tester <tester@mail>``362 363 - Reviewed-by: ``Reviewer <reviewer@mail>``364 365 - Acked-by: ``Acker <acker@mail>``366 367 - Cc: ``cc-ed-person <person@mail>``368 369 If the patch should be backported to stable, then please add a '``Cc:370 stable@vger.kernel.org``' tag, but do not Cc stable when sending your371 mail.372 373 - Link: ``https://link/to/information``374 375 For referring to an email posted to the kernel mailing lists, please376 use the lore.kernel.org redirector URL::377 378 Link: https://lore.kernel.org/email-message-id@here379 380 This URL should be used when referring to relevant mailing list381 topics, related patch sets, or other notable discussion threads.382 A convenient way to associate ``Link:`` trailers with the commit383 message is to use markdown-like bracketed notation, for example::384 385 A similar approach was attempted before as part of a different386 effort [1], but the initial implementation caused too many387 regressions [2], so it was backed out and reimplemented.388 389 Link: https://lore.kernel.org/some-msgid@here # [1]390 Link: https://bugzilla.example.org/bug/12345 # [2]391 392 You can also use ``Link:`` trailers to indicate the origin of the393 patch when applying it to your git tree. In that case, please use the394 dedicated ``patch.msgid.link`` domain instead of ``lore.kernel.org``.395 This practice makes it possible for automated tooling to identify396 which link to use to retrieve the original patch submission. For397 example::398 399 Link: https://patch.msgid.link/patch-source-message-id@here400 401Please do not use combined tags, e.g. ``Reported-and-tested-by``, as402they just complicate automated extraction of tags.403 404 405Links to documentation406^^^^^^^^^^^^^^^^^^^^^^407 408Providing links to documentation in the changelog is a great help to later409debugging and analysis. Unfortunately, URLs often break very quickly410because companies restructure their websites frequently. Non-'volatile'411exceptions include the Intel SDM and the AMD APM.412 413Therefore, for 'volatile' documents, please create an entry in the kernel414bugzilla https://bugzilla.kernel.org and attach a copy of these documents415to the bugzilla entry. Finally, provide the URL of the bugzilla entry in416the changelog.417 418Patch resend or reminders419^^^^^^^^^^^^^^^^^^^^^^^^^420 421See :ref:`resend_reminders`.422 423Merge window424^^^^^^^^^^^^425 426Please do not expect patches to be reviewed or merged by tip427maintainers around or during the merge window. The trees are closed428to all but urgent fixes during this time. They reopen once the merge429window closes and a new -rc1 kernel has been released.430 431Large series should be submitted in mergeable state *at* *least* a week432before the merge window opens. Exceptions are made for bug fixes and433*sometimes* for small standalone drivers for new hardware or minimally434invasive patches for hardware enablement.435 436During the merge window, the maintainers instead focus on following the437upstream changes, fixing merge window fallout, collecting bug fixes, and438allowing themselves a breath. Please respect that.439 440So called _urgent_ branches will be merged into mainline during the441stabilization phase of each release.442 443 444Git445^^^446 447The tip maintainers accept git pull requests from maintainers who provide448subsystem changes for aggregation in the tip tree.449 450Pull requests for new patch submissions are usually not accepted and do not451replace proper patch submission to the mailing list. The main reason for452this is that the review workflow is email based.453 454If you submit a larger patch series it is helpful to provide a git branch455in a private repository which allows interested people to easily pull the456series for testing. The usual way to offer this is a git URL in the cover457letter of the patch series.458 459Testing460^^^^^^^461 462Code should be tested before submitting to the tip maintainers. Anything463other than minor changes should be built, booted and tested with464comprehensive (and heavyweight) kernel debugging options enabled.465 466These debugging options can be found in kernel/configs/x86_debug.config467and can be added to an existing kernel config by running:468 469 make x86_debug.config470 471Some of these options are x86-specific and can be left out when testing472on other architectures.473 474.. _maintainer-tip-coding-style:475 476Coding style notes477------------------478 479Comment style480^^^^^^^^^^^^^481 482Sentences in comments start with an uppercase letter.483 484Single line comments::485 486 /* This is a single line comment */487 488Multi-line comments::489 490 /*491 * This is a properly formatted492 * multi-line comment.493 *494 * Larger multi-line comments should be split into paragraphs.495 */496 497No tail comments (see below):498 499 Please refrain from using tail comments. Tail comments disturb the500 reading flow in almost all contexts, but especially in code::501 502 if (somecondition_is_true) /* Don't put a comment here */503 dostuff(); /* Neither here */504 505 seed = MAGIC_CONSTANT; /* Nor here */506 507 Use freestanding comments instead::508 509 /* This condition is not obvious without a comment */510 if (somecondition_is_true) {511 /* This really needs to be documented */512 dostuff();513 }514 515 /* This magic initialization needs a comment. Maybe not? */516 seed = MAGIC_CONSTANT;517 518 Use C++ style, tail comments when documenting structs in headers to519 achieve a more compact layout and better readability::520 521 // eax522 u32 x2apic_shift : 5, // Number of bits to shift APIC ID right523 // for the topology ID at the next level524 : 27; // Reserved525 // ebx526 u32 num_processors : 16, // Number of processors at current level527 : 16; // Reserved528 529 versus::530 531 /* eax */532 /*533 * Number of bits to shift APIC ID right for the topology ID534 * at the next level535 */536 u32 x2apic_shift : 5,537 /* Reserved */538 : 27;539 540 /* ebx */541 /* Number of processors at current level */542 u32 num_processors : 16,543 /* Reserved */544 : 16;545 546Comment the important things:547 548 Comments should be added where the operation is not obvious. Documenting549 the obvious is just a distraction::550 551 /* Decrement refcount and check for zero */552 if (refcount_dec_and_test(&p->refcnt)) {553 do;554 lots;555 of;556 magic;557 things;558 }559 560 Instead, comments should explain the non-obvious details and document561 constraints::562 563 if (refcount_dec_and_test(&p->refcnt)) {564 /*565 * Really good explanation why the magic things below566 * need to be done, ordering and locking constraints,567 * etc..568 */569 do;570 lots;571 of;572 magic;573 /* Needs to be the last operation because ... */574 things;575 }576 577Function documentation comments:578 579 To document functions and their arguments please use kernel-doc format580 and not free form comments::581 582 /**583 * magic_function - Do lots of magic stuff584 * @magic: Pointer to the magic data to operate on585 * @offset: Offset in the data array of @magic586 *587 * Deep explanation of mysterious things done with @magic along588 * with documentation of the return values.589 *590 * Note, that the argument descriptors above are arranged591 * in a tabular fashion.592 */593 594 This applies especially to globally visible functions and inline595 functions in public header files. It might be overkill to use kernel-doc596 format for every (static) function which needs a tiny explanation. The597 usage of descriptive function names often replaces these tiny comments.598 Apply common sense as always.599 600 601Documenting locking requirements602^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^603 Documenting locking requirements is a good thing, but comments are not604 necessarily the best choice. Instead of writing::605 606 /* Caller must hold foo->lock */607 void func(struct foo *foo)608 {609 ...610 }611 612 Please use::613 614 void func(struct foo *foo)615 {616 lockdep_assert_held(&foo->lock);617 ...618 }619 620 In PROVE_LOCKING kernels, lockdep_assert_held() emits a warning621 if the caller doesn't hold the lock. Comments can't do that.622 623Bracket rules624^^^^^^^^^^^^^625 626Brackets should be omitted only if the statement which follows 'if', 'for',627'while' etc. is truly a single line::628 629 if (foo)630 do_something();631 632The following is not considered to be a single line statement even633though C does not require brackets::634 635 for (i = 0; i < end; i++)636 if (foo[i])637 do_something(foo[i]);638 639Adding brackets around the outer loop enhances the reading flow::640 641 for (i = 0; i < end; i++) {642 if (foo[i])643 do_something(foo[i]);644 }645 646 647Variable declarations648^^^^^^^^^^^^^^^^^^^^^649 650The preferred ordering of variable declarations at the beginning of a651function is reverse fir tree order::652 653 struct long_struct_name *descriptive_name;654 unsigned long foo, bar;655 unsigned int tmp;656 int ret;657 658The above is faster to parse than the reverse ordering::659 660 int ret;661 unsigned int tmp;662 unsigned long foo, bar;663 struct long_struct_name *descriptive_name;664 665And even more so than random ordering::666 667 unsigned long foo, bar;668 int ret;669 struct long_struct_name *descriptive_name;670 unsigned int tmp;671 672Also please try to aggregate variables of the same type into a single673line. There is no point in wasting screen space::674 675 unsigned long a;676 unsigned long b;677 unsigned long c;678 unsigned long d;679 680It's really sufficient to do::681 682 unsigned long a, b, c, d;683 684Please also refrain from introducing line splits in variable declarations::685 686 struct long_struct_name *descriptive_name = container_of(bar,687 struct long_struct_name,688 member);689 struct foobar foo;690 691It's way better to move the initialization to a separate line after the692declarations::693 694 struct long_struct_name *descriptive_name;695 struct foobar foo;696 697 descriptive_name = container_of(bar, struct long_struct_name, member);698 699 700Variable types701^^^^^^^^^^^^^^702 703Please use the proper u8, u16, u32, u64 types for variables which are meant704to describe hardware or are used as arguments for functions which access705hardware. These types are clearly defining the bit width and avoid706truncation, expansion and 32/64-bit confusion.707 708u64 is also recommended in code which would become ambiguous for 32-bit709kernels when 'unsigned long' would be used instead. While in such710situations 'unsigned long long' could be used as well, u64 is shorter711and also clearly shows that the operation is required to be 64 bits wide712independent of the target CPU.713 714Please use 'unsigned int' instead of 'unsigned'.715 716 717Constants718^^^^^^^^^719 720Please do not use literal (hexa)decimal numbers in code or initializers.721Either use proper defines which have descriptive names or consider using722an enum.723 724 725Struct declarations and initializers726^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^727 728Struct declarations should align the struct member names in a tabular729fashion::730 731 struct bar_order {732 unsigned int guest_id;733 int ordered_item;734 struct menu *menu;735 };736 737Please avoid documenting struct members within the declaration, because738this often results in strangely formatted comments and the struct members739become obfuscated::740 741 struct bar_order {742 unsigned int guest_id; /* Unique guest id */743 int ordered_item;744 /* Pointer to a menu instance which contains all the drinks */745 struct menu *menu;746 };747 748Instead, please consider using the kernel-doc format in a comment preceding749the struct declaration, which is easier to read and has the added advantage750of including the information in the kernel documentation, for example, as751follows::752 753 754 /**755 * struct bar_order - Description of a bar order756 * @guest_id: Unique guest id757 * @ordered_item: The item number from the menu758 * @menu: Pointer to the menu from which the item759 * was ordered760 *761 * Supplementary information for using the struct.762 *763 * Note, that the struct member descriptors above are arranged764 * in a tabular fashion.765 */766 struct bar_order {767 unsigned int guest_id;768 int ordered_item;769 struct menu *menu;770 };771 772Static struct initializers must use C99 initializers and should also be773aligned in a tabular fashion::774 775 static struct foo statfoo = {776 .a = 0,777 .plain_integer = CONSTANT_DEFINE_OR_ENUM,778 .bar = &statbar,779 };780 781Note that while C99 syntax allows the omission of the final comma,782we recommend the use of a comma on the last line because it makes783reordering and addition of new lines easier, and makes such future784patches slightly easier to read as well.785 786Line breaks787^^^^^^^^^^^788 789Restricting line length to 80 characters makes deeply indented code hard to790read. Consider breaking out code into helper functions to avoid excessive791line breaking.792 793The 80 character rule is not a strict rule, so please use common sense when794breaking lines. Especially format strings should never be broken up.795 796When splitting function declarations or function calls, then please align797the first argument in the second line with the first argument in the first798line::799 800 static int long_function_name(struct foobar *barfoo, unsigned int id,801 unsigned int offset)802 {803 804 if (!id) {805 ret = longer_function_name(barfoo, DEFAULT_BARFOO_ID,806 offset);807 ...808 809Namespaces810^^^^^^^^^^811 812Function/variable namespaces improve readability and allow easy813grepping. These namespaces are string prefixes for globally visible814function and variable names, including inlines. These prefixes should815combine the subsystem and the component name such as 'x86_comp\_',816'sched\_', 'irq\_', and 'mutex\_'.817 818This also includes static file scope functions that are immediately put819into globally visible driver templates - it's useful for those symbols820to carry a good prefix as well, for backtrace readability.821 822Namespace prefixes may be omitted for local static functions and823variables. Truly local functions, only called by other local functions,824can have shorter descriptive names - our primary concern is greppability825and backtrace readability.826 827Please note that 'xxx_vendor\_' and 'vendor_xxx_` prefixes are not828helpful for static functions in vendor-specific files. After all, it829is already clear that the code is vendor-specific. In addition, vendor830names should only be for truly vendor-specific functionality.831 832As always apply common sense and aim for consistency and readability.833 834 835Commit notifications836--------------------837 838The tip tree is monitored by a bot for new commits. The bot sends an email839for each new commit to a dedicated mailing list840(``linux-tip-commits@vger.kernel.org``) and Cc's all people who are841mentioned in one of the commit tags. It uses the email message ID from the842Link tag at the end of the tag list to set the In-Reply-To email header so843the message is properly threaded with the patch submission email.844 845The tip maintainers and submaintainers try to reply to the submitter846when merging a patch, but they sometimes forget or it does not fit the847workflow of the moment. While the bot message is purely mechanical, it848also implies a 'Thank you! Applied.'.849