| /linux-6.3-rc2/Documentation/process/ |
| A D | applying-patches.rst | 21 their specific patches) is also provided.
145 only patches from kernel.org and you apply the patches in the correct order,
241 Where can I download the patches?
248 The 5.x.y (-stable) and 5.x patches live at
252 The 5.x.y incremental patches live at
261 The stable -rc patches live at
316 how to apply these patches.
318 Normal patches
337 Incremental patches
403 The -mm patches and the linux-next tree
[all …]
|
| A D | email-clients.rst | 11 end, maintainers use ``git am`` to apply the patches.
44 Emailed patches should be in ASCII or UTF-8 encoding only.
56 Don't use PGP/GPG signatures in mail that contains patches.
57 This breaks many scripts that read and apply the patches.
69 patches for the Linux kernel. These are not meant to be complete
95 Works. Some people use this successfully for patches.
108 Some people use this successfully for patches.
124 Some people use Kmail successfully for patches.
153 patches so do not GPG sign them. Signing patches that have been inserted
216 using Mutt to send patches through Gmail::
[all …]
|
| A D | 5.Posting.rst | 3 Posting patches
9 of conventions and procedures which are used in the posting of patches;
13 :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
20 There is a constant temptation to avoid posting patches before they are
21 completely "ready." For simple patches, that is not a problem. If the
30 patches which are known to be half-baked, but those who do will come in
34 Before creating patches
38 sending patches to the development community. These include:
63 The preparation of patches for posting can be a surprising amount of work,
81 up patches is a bit of an art; some developers spend a long time figuring
[all …]
|
| A D | stable-kernel-rules.rst | 6 Rules on what kind of patches are accepted, and which ones are not, into the
30 :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
35 Procedure for submitting patches to the -stable tree
40 Security patches should not be handled (solely) by the -stable review
106 Additionally, some patches submitted via :ref:`option_1` may have additional
127 Also, some patches may have kernel version prerequisites. This can be
162 - The ACKed patches will be posted again as part of release candidate (-rc)
165 issues, some patches may be modified or dropped or additional patches may
172 containing all the queued and tested patches.
173 - Security patches will be accepted into the -stable tree directly from the
[all …]
|
| A D | maintainer-netdev.rst | 14 - don't post large series (> 15 patches), break them up
15 - don't repost your patches within one 24h period
89 RFC patches sent for review only are obviously welcome at any time
139 Generally speaking, the patches get triaged quickly (in less than
150 patches such that it is clear this is the latest and greatest set of patches
153 Handling misapplied patches
188 alongside kernel patches. This gives reviewers a chance to see
194 to a public repo where user space patches can be seen.
197 reviewed on netdev (e.g. patches to ``iproute2`` tools) kernel and
241 Dividing work into patches
[all …]
|
| A D | 2.Process.rst | 36 merging of patches for each release. At the beginning of each development
41 this time, at a rate approaching 1,000 changes ("patches," or "changesets")
57 Over the next six to ten weeks, only patches which fix problems should be
209 How patches get into the Kernel
213 repository: Linus Torvalds. But, for example, of the over 9,500 patches
233 patches in his or her repository are not found in the mainline.
237 Linus agrees, the stream of patches will flow up into his repository,
241 trusts the subsystem maintainers to not send bad patches upstream.
275 trees; it also has some patches aimed at helping with debugging.
285 development cycle, approximately 5-10% of the patches going into the
[all …]
|
| A D | 7.AdvancedTopics.rst | 11 Managing patches with git
23 Managing patches with git can make life much easier for the developer,
24 especially as the volume of those patches grows. Git also has its rough
39 understanding of how git works before trying to use it to make patches
49 Using git to generate patches for submission by email can be a good
65 Publicly-available branches should be created with care; merge in patches
123 You can send me patches, but for me to pull a git patch from you, I
130 To avoid this kind of situation, ensure that all patches within a given
137 If and when others start to send patches for inclusion into your tree,
150 Reviewing patches
[all …]
|
| A D | submitting-patches.rst | 3 Submitting patches: the essential guide to getting your code into the kernel
16 For device tree binding patches, read
17 Documentation/devicetree/bindings/submitting-patches.rst.
168 driver which uses that new API, separate those into two patches.
305 your e-mail client so that it sends your patches untouched.
372 patches that are being emailed around.
508 future patches, and ensures credit for the testers.
642 If there are four patches in a patch series the individual patches may
787 $ git am patches.mbox
836 Andi Kleen, "On submitting kernel patches"
[all …]
|
| A D | howto.rst | 12 If anything in this document becomes out of date, please send in patches
105 patches if these rules are followed, and many people will only
120 Other excellent descriptions of how to create patches properly are:
163 :ref:`Documentation/process/applying-patches.rst <applying_patches>`
251 Linus, usually the patches that have already been included in the
264 patches to Linus after -rc1 is released, but the patches need to also be
323 revisions to it, and maintainers can mark patches as under review,
419 attachments or compressed patches; they may want to comment on
445 them at a technical level and either rework your patches or provide
484 - "Here is a series of small patches that..."
[all …]
|
| A D | 6.Followthrough.rst | 8 patches. One of the biggest mistakes that even experienced kernel
10 posting patches indicates a transition into the next stage of the process,
19 prevent the inclusion of your patches into the mainline.
81 that your patches go nowhere.
112 dedicated to patches planned for the next merge window, and another for
115 For patches applying to areas for which there is no obvious subsystem tree
116 (memory management patches, for example), the default tree often ends up
130 burner so that the remaining patches can be worked into shape and merged.
132 developers and, possibly, moving some patches between trees to ensure that
198 acceptable to you. There is a certain resistance to merging patches which
[all …]
|
| A D | researcher-guidelines.rst | 47 To help clarify: sending patches to developers *is* interacting
49 contributions*. Sending intentionally flawed/vulnerable patches or
69 * Documentation/process/submitting-patches.rst
76 When sending patches produced from research, the commit logs should
131 (This is required if you have been explicitly told your patches need
137 resulting patches, and there by reduces the burden on other developers.
139 If no one can be found to internally review patches and you need
|
| A D | index.rst | 28 submitting-patches
60 applying-patches
|
| /linux-6.3-rc2/Documentation/translations/zh_CN/process/ |
| A D | 5.Posting.rst | 22 :ref:`Documentation/translations/zh_CN/process/submitting-patches.rst <cn_submittingpatches>`
154 :ref:`Documentation/translations/zh_CN/process/submitting-patches.rst <cn_submittingpatches>`
165 :ref:`Documentation/translations/zh_CN/process/submitting-patches.rst <cn_submittingpatches>`
172 :ref:`Documentation/translations/zh_CN/process/submitting-patches.rst <cn_submittingpatches>`
180 :ref:`Documentation/translations/zh_CN/process/submitting-patches.rst <cn_submittingpatches>`
|
| /linux-6.3-rc2/Documentation/translations/zh_TW/process/ |
| A D | 5.Posting.rst | 25 :ref:`Documentation/translations/zh_TW/process/submitting-patches.rst <tw_submittingpatches>`
157 :ref:`Documentation/translations/zh_TW/process/submitting-patches.rst <tw_submittingpatches>`
168 :ref:`Documentation/translations/zh_TW/process/submitting-patches.rst <tw_submittingpatches>`
175 :ref:`Documentation/translations/zh_TW/process/submitting-patches.rst <tw_submittingpatches>`
183 :ref:`Documentation/translations/zh_TW/process/submitting-patches.rst <tw_submittingpatches>`
|
| /linux-6.3-rc2/Documentation/bpf/ |
| A D | bpf_devel_QA.rst | 7 patches for stable kernels.
9 For general information about submitting patches, please refer to
44 Submitting patches
74 Q: To which mailing list do I need to submit my BPF patches?
83 the changes and provide their Acked-by's to the patches.
94 patches under review can be found at:
123 which branch patches should get rebased to.
169 the patches.
222 accumulate too many patches in bpf or bpf-next.
421 Q: Queue stable patches
[all …]
|
| /linux-6.3-rc2/Documentation/livepatch/ |
| A D | cumulative-patches.rst | 5 There might be dependencies between livepatches. If multiple patches need
7 an order in which the patches will be installed. And function implementations
10 This might become a maintenance nightmare. Especially when more patches
30 Once the transition is finished, all older patches are automatically
65 to reverse it and restore the replaced patches atomically.
78 executed. Any callbacks from the replaced patches are ignored.
83 As a result, it might be dangerous to replace newer cumulative patches by
93 enabled patches were called.
|
| /linux-6.3-rc2/drivers/scsi/aic7xxx/aicasm/ |
| A D | aicasm.c | 74 STAILQ_HEAD(patch_list, patch) patches;
126 STAILQ_INIT(&patches); in main()
425 for (cur_patch = STAILQ_FIRST(&patches); in output_code()
429 cur_patch == STAILQ_FIRST(&patches) ? "" : ",\n", in output_code()
493 pinfo = &scope->patches[patch]; in emit_patch()
515 STAILQ_INSERT_TAIL(&patches, new_patch, links); in emit_patch()
596 cur_patch = STAILQ_FIRST(&patches); in output_listing()
804 cur_scope->patches[1].skip_patch = in process_scope()
806 cur_scope->patches[1].skip_instr = in process_scope()
816 cur_scope->patches[0].skip_patch = patch0_patch_skip; in process_scope()
[all …]
|
| /linux-6.3-rc2/Documentation/maintainer/ |
| A D | maintainer-entry-profile.rst | 7 (submitting-patches, submitting drivers...) with
18 tells the contributor where to send patches for which files, it does not
24 - Are there notifications when patches are applied to the local tree, or
47 require published specifications at a certain revision before patches
53 One of the common misunderstandings of submitters is that patches can be
55 considered for the next -rc1. The reality is that most patches need to
58 week) that patches might be considered for merging and when patches need to
|
| /linux-6.3-rc2/Documentation/nvdimm/ |
| A D | maintainer-entry-profile.rst | 15 In general patches can be submitted against the latest -rc; however, if
19 are cases where patches are more suitable to be merged through a
32 Those tests need to be passed before the patches go upstream, but not
38 Before patches enabling a new _DSM family will be considered, it must
52 and some patches may require multiple development cycles to review.
|
| /linux-6.3-rc2/Documentation/driver-api/acpi/ |
| A D | linuxized-acpica.rst | 125 Linux patches. The patches generated by this process are referred to as
126 "linuxized ACPICA patches". The release process is carried out on a local
182 Before the linuxized ACPICA patches are sent to the Linux ACPI community
191 Ideally, all of the ACPICA commits should be converted into Linux patches
219 user space simulation utilities, thus the linuxized ACPICA patches may
222 linuxized ACPICA patches during the release process. When the release
236 utilities to obtain Linux patches corresponding to upstream ACPICA commits
260 top of the generated ACPICA release patches::
264 $ generate/linux/make-patches.sh -u [commit ID]
|
| /linux-6.3-rc2/Documentation/mm/damon/ |
| A D | maintainer-profile.rst | 18 Suffieicntly reviewed patches will be queued in mm-unstable [1]_ by the memory
19 management subsystem maintainer. After more sufficient tests, the patches will
23 Note again the patches for review should be made against the mm-unstable
51 Mon-Fri) in PST. The response to patches will occasionally be slow. Do not
|
| /linux-6.3-rc2/Documentation/driver-api/media/ |
| A D | maintainer-entry-profile.rst | 28 must be kept in sync with the API changes. It means that all patches that
35 task to review the patches, providing feedback to users if the patches are
122 Those tests need to pass before the patches go upstream.
134 Be sure to not introduce new warnings on your patches without a
158 In principle, patches should follow the coding style rules, but exceptions
196 Except for bug fixes, we don't usually add new patches to the development
200 could take a while for us to be able to review your patches. Feel free
|
| /linux-6.3-rc2/scripts/package/ |
| A D | mkdebian | 144 mkdir -p debian/patches
152 } > debian/patches/config
153 echo config > debian/patches/series
|
| /linux-6.3-rc2/Documentation/translations/it_IT/process/ |
| A D | index.rst | 29 submitting-patches
57 applying-patches
|
| /linux-6.3-rc2/scripts/coccinelle/misc/ |
| A D | minmax.cocci | 4 /// Generated patches sometimes require adding a cast to fix compile warning.
5 /// Warnings/patches scope intentionally limited to a function body.
119 // Don't generate patches for errcode returns.
|