| /openbmc/qemu/docs/devel/ |
| H A D | trivial-patches.rst | 1 .. _trivial-patches:
3 Trivial Patches
9 Trivial patches that change just a few lines of code sometimes languish
11 review. This is often the case for patches that do not fall under an
14 The trivial patches team take on the task of reviewing and building pull
15 requests for patches that:
18 - Are single patches or short series (max 2-4 patches).
30 …git://github.com/vivier/qemu.git trivial-patches - `browse <https://github.com/vivier/qemu/tree/tr…
35 The trivial patches team rotates the duty of collecting trivial patches
38 1. Identify trivial patches on the development mailing list.
[all …]
|
| H A D | submitting-a-patch.rst | 7 the documentation. However, we get a lot of patches, and so we have
15 .. list-table:: Minimal Checklist for Patches
21 * - Patches contain Signed-off-by: Your Name <author@email>
47 Writing your Patches
66 Base patches against current git master
74 It is also okay to base patches on top of other on-going work that is
83 Split up long patches
86 Split up longer patches into a patch series of logical code changes.
96 good candidate for splitting into multiple patches. For more thoughts on
97 properly splitting patches and writing good commit messages, see `this
[all …]
|
| H A D | stable-process.rst | 22 Generally, the following patches are considered stable material:
24 * Patches that fix severe issues, like fixes for CVEs
26 * Patches that fix regressions
47 patches that are stable candidates are tracked by the maintainers.
67 a git branch with a release candidate and send the patches out to
68 ``qemu-devel@nongnu.org`` for review. If any of your patches are included,
71 nominate other patches that you think are suitable for inclusion. After
|
| /openbmc/linux/Documentation/process/ |
| H A D | applying-patches.rst | 3 Applying Patches To The Linux Kernel
19 In addition to explaining how to apply and revert patches, a brief
21 their specific patches) is also provided.
28 different versions of a source tree. Patches are created with the ``diff``
43 Patches for the Linux kernel are generated relative to the parent directory
144 If you don't have any third-party patches applied to your kernel source, but
145 only patches from kernel.org and you apply the patches in the correct order,
157 in the wrong directory. Less often, you'll find patches that need to be
203 So if you get these errors with kernel.org patches then you should probably
216 generate a patch representing the differences between two patches and then
[all …]
|
| H 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,
67 Patches must be prepared against a specific version of the kernel. As a
[all …]
|
| H 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
93 serious. For this reason, patches which cause regressions are looked upon
143 Patches do not go directly from the developer's keyboard into the mainline
165 - Early review. Patches are posted to the relevant mailing list, and
209 How patches get into the Kernel
212 There is exactly one person who can merge patches into the mainline kernel
213 repository: Linus Torvalds. But, for example, of the over 9,500 patches
231 maintainers to track a list of patches, including authorship information
[all …]
|
| H A D | email-clients.rst | 11 end, maintainers use ``git am`` to apply the patches.
21 Patches for the Linux kernel are submitted via email, preferably as
29 for patches and other emails alike. https://useplaintext.email may be useful
33 Email clients that are used for Linux kernel patches should send the
37 Don't send patches with ``format=flowed``. This can cause unexpected
44 Emailed patches should be in ASCII or UTF-8 encoding only.
51 Copy-and-paste (or cut-and-paste) usually does not work for patches
56 Don't use PGP/GPG signatures in mail that contains patches.
57 This breaks many scripts that read and apply the patches.
61 and successfully apply it with 'patch' before sending patches to Linux
[all …]
|
| H 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
141 patches set to ``Awaiting upstream`` in netdev's patchwork
149 pw-bot can automatically set patches to this state based
153 Patches are indexed by the ``Message-ID`` header of the emails
162 about the history of the state of patches, therefore having multiple
177 completely. Maintainers will classify and update the state of the patches
181 The use of the bot is restricted to authors of the patches (the ``From:``
193 Generally speaking, the patches get triaged quickly (in less than
[all …]
|
| H 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
115 mass movement of patches from one repository to another makes it easy to
118 thing happening; putting up a git tree with unreviewed or off-topic 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
[all …]
|
| H A D | stable-kernel-rules.rst | 6 Rules on what kind of patches are accepted, and which ones are not, into the
13 :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
34 Procedure for submitting patches to the -stable tree
39 Security patches should not be handled (solely) by the -stable review
104 * For patches that may have kernel version prerequisites specify them using
122 * To delay pick up of patches, use the following format:
184 - When the -stable maintainers decide for a review cycle, the patches will be
192 - The ACKed patches will be posted again as part of release candidate (-rc)
195 issues, some patches may be modified or dropped or additional patches may
202 containing all the queued and tested patches.
[all …]
|
| /openbmc/openbmc/meta-arm/ci/ |
| H A D | patchreview | 66 def patchreview(patches): argument
77 for patch in patches:
109 # Check that patches which looks like CVEs have CVE tags
144 # Count patches with no status as pending
193 print("""Total patches found: %d
194 Patches missing Signed-off-by: %s
195 Patches with malformed Signed-off-by: %s
196 Patches missing CVE: %s
197 Patches missing Upstream-Status: %s
198 Patches with malformed Upstream-Status: %s
[all …]
|
| /openbmc/openbmc/meta-arm/meta-arm/classes/ |
| H A D | apply_local_src_patches.bbclass | 1 # This class is to be inherited by recipes where there are patches located inside
5 # LOCAL_SRC_PATCHES_INPUT_DIR is the directory from where the patches are located
6 # LOCAL_SRC_PATCHES_DEST_DIR is the directory where the patches will be applied
32 export QUILT_PATCHES=./patches-extra
33 mkdir -p patches-extra
35 bbdebug 1 "Looking for patches in $input_dir"
41 echo $patch_basename >> patches-extra/series
42 cp $patch patches-extra
|
| /openbmc/openbmc/poky/documentation/contributor-guide/ |
| H A D | submit-changes.rst | 17 maintained by patches being submitted on mailing lists. We appreciate this
68 By default, Git adds a signature line at the end of patches containing the Git
107 corresponding to each of the patches you will eventually submit.
108 See `further guidance <https://www.kernel.org/doc/html/latest/process/submitting-patches.html#separ…
134 …<https://www.kernel.org/doc/html/latest/process/submitting-patches.html#sign-your-work-the-develop…
220 yourself if you submitted your patches to early reviewers,
228 …<https://www.kernel.org/doc/html/latest/process/submitting-patches.html#using-reported-by-tested-b…
263 Creating Patches
266 Here is the general procedure on how to create patches to be sent through email:
270 the series of patches you are about to send.
[all …]
|
| /openbmc/openbmc/meta-openembedded/meta-oe/recipes-multimedia/id3lib/ |
| H A D | id3lib_3.8.3.bb | 22 # patches maintained by quilt. So manually apply them before applying other local
23 # patches. Also remove all temp files before leaving, because do_patch() will pop
24 # up all previously applied patches in the start
28 # it's important that we only pop the existing patches when they've
30 # and reverse out some completely different set of patches
31 if [ -d ${S}/patches ]; then
36 QUILT_PATCHES=${S}/patches quilt pop -a
41 QUILT_PATCHES=${S}/debian/patches quilt pop -a
44 QUILT_PATCHES=${S}/debian/patches quilt push -a
|
| /openbmc/linux/Documentation/bpf/ |
| H A D | bpf_devel_QA.rst | 6 workflows related to reporting bugs, submitting patches, and queueing
7 patches for stable kernels.
9 For general information about submitting patches, please refer to
10 Documentation/process/submitting-patches.rst. This document only describes
44 Submitting patches
49 A: BPF CI is GitHub based and hosted at https://github.com/kernel-patches/bpf.
53 The following steps lay out how to start a CI run for your patches:
59 or bpf branch, and apply your to-be-tested patches on top of it
62 kernel-patches/bpf's bpf-next_base or bpf_base branch, respectively
65 that capacity is shared with patches submitted upstream being checked and so
[all …]
|
| /openbmc/linux/Documentation/livepatch/ |
| H A D | cumulative-patches.rst | 2 Atomic Replace & Cumulative Patches
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
14 creation of so called "Cumulative Patches". They include all wanted changes
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.
|
| /openbmc/u-boot/tools/patman/ |
| H A D | README | 11 - Runs the patches through checkpatch.pl and its own checks
29 patches automatically (unless you use -m to disable this).
46 patches. Weeks later, change the patches and repeat, knowing that you
61 out where to send patches pretty well.
85 If you want to avoid sending patches to email addresses that are picked up
135 If it can't detect the upstream branch, try telling it how many patches
179 RFC patches, or RESEND if you are being ignored. The patch subject
221 A sign-off is added automatically to your patches (this is
222 probably a bug). If you put this tag in your patches, it will
273 patch series and see how the patches turn out.
[all …]
|
| /openbmc/openbmc/poky/scripts/contrib/ |
| H A D | patchreview.py | 56 def patchreview(patches): argument
68 for patch in patches:
100 # Check that patches which looks like CVEs have CVE tags
141 # Count patches with no status as pending
186 print("""Total patches found: %d
187 Patches missing Signed-off-by: %s
188 Patches with malformed Signed-off-by: %s
189 Patches missing CVE: %s
190 Patches missing Upstream-Status: %s
191 Patches with malformed Upstream-Status: %s
[all …]
|
| /openbmc/openbmc/poky/documentation/kernel-dev/ |
| H A D | advanced.rst | 10 In addition to supporting configuration fragments and patches, the Yocto
104 variable to include features (configuration fragments, patches, or both)
129 [1]_ description files, configuration fragments, and patches. The
143 Features aggregate sources in the form of patches and configuration
146 pure configuration fragments, simple patches, complex features, and
154 of configuration fragments, patches, features or kernel types, best
163 patches/
176 ``patches`` directory.
181 - If your file aggregates non-hardware configuration and patches in
189 because all of ``cfg``, ``features``, ``patches``, and ``ktypes``,
[all …]
|
| /openbmc/openbmc/poky/meta/lib/oe/ |
| H A D | patch.py | 77 self.patches = []
86 patches and wiping out all associated metadata.
189 self.patchdir = os.path.join(self.dir, 'patches')
190 self.seriespath = os.path.join(self.dir, 'patches', 'series')
209 patches = f.readlines()
211 for p in reversed(patches):
213 patches = []
215 self._removePatch(os.path.join(self.patchdir, patches[-1].strip()))
216 patches.pop()
218 for p in patches:
[all …]
|
| /openbmc/openbmc/meta-raspberrypi/docs/ |
| H A D | contributing.md | 14 ## Formatting patches
70 the above formatting guidelines carefully before sending your patches.
72 ## Sending patches
79 **In addition**, you may send patches for review to the above specified
80 mailing list. In this case, when creating patches using `git` please make
85 Then, for sending patches to the mailing list, you may use this command:
89 When patches are sent through the mailing list, the maintainer will include
90 them in a GitHub pull request that will take the patches through the CI
100 If you submit patches that have a GitHub issue associated, please make sure to
|
| /openbmc/linux/Documentation/maintainer/ |
| H 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
63 their first posting for consideration before this point. Patches that
|
| /openbmc/linux/Documentation/mm/damon/ |
| H A D | maintainer-profile.rst | 10 linux-mm@kvack.org. Patches should be made against the mm-unstable tree [1]_
16 There are multiple Linux trees for DAMON development. Patches under
18 Sufficiently 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
44 Patches can be sent anytime. Key cycle dates of the mm-unstable[1] and
51 Mon-Fri) in PST. The response to patches will occasionally be slow. Do not
|
| /openbmc/docs/ |
| H A D | kernel-development.md | 9 contains the set of patches that we carry. Ideally there would be no patches
18 3. Patches included in the OpenBMC tree temporarily
41 process)[https://www.kernel.org/doc/Documentation/process/submitting-patches.rst].
43 In the past patches underwent 'pre-review' on the OpenBMC mailing list. While
58 chose to carry the patches in the OpenBMC tree while the upstream development is
61 Another exception to the upstream first rule is where patches are modifying
68 email to the OpenBMC list to get the opinion of the kernel developers. Patches
88 Before submitting patches it is recommended you boot test on at least the Qemu
|
| /openbmc/openbmc/poky/scripts/ |
| H A D | send-pull-request | 29 Signed-off-by lines found in the cover letter and the patches.
31 -c Expand the Cc list for the individual patches using the Cc and
117 # Harvest emails from the generated patches and populate AUTO_CC.
151 PATCHES=$(echo $PDIR/*.patch)
154 # harvested. Then remove it from the patches list.
162 PATCHES=${PATCHES/"$CL"/}
167 eval "git send-email $GIT_TO $GIT_EXTRA_CC --confirm=always --no-thread $GITSOBCC $PATCHES"
169 echo "ERROR: failed to send patches."
|