| /openbmc/qemu/docs/devel/ |
| H A D | trivial-patches.rst | 1 .. _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.
39 2. Review trivial patches, merge them into a git tree, and reply to state
[all …]
|
| H A D | submitting-a-patch.rst | 7 the documentation. However, we get a lot of patches, and so we have
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
103 Make code motion patches easy to review
112 property ensures file rename patches will be given in a more compact
141 For smaller patches in less frequently changed areas of QEMU, consider
[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/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/openbmc/poky/meta/lib/oeqa/selftest/cases/ |
| H A D | recipeutils.py | 32 …patches = oe.recipeutils.patch_recipe(rd, rd.getVar('FILE'), vals, patch=True, relpath=metaselftes…
56 for f in patches:
70 …patches = oe.recipeutils.patch_recipe(rd, rd.getVar('FILE'), vals, patch=True, relpath=metaselftes…
84 for f in patches:
95 …patches = oe.recipeutils.patch_recipe(rd, rd.getVar('FILE'), vals, patch=True, relpath=metaselftes…
109 for f in patches:
|
| /openbmc/linux/scripts/package/ |
| H A D | mkdebian | 100 mkdir -p debian/patches
108 } > debian/patches/config.patch
109 echo config.patch > debian/patches/series
111 "${srctree}/scripts/package/gen-diff-patch" debian/patches/diff.patch
112 if [ -s debian/patches/diff.patch ]; then
117 " debian/patches/diff.patch
119 echo diff.patch >> debian/patches/series
121 rm -f debian/patches/diff.patch
|
| /openbmc/linux/Documentation/process/ |
| H A D | applying-patches.rst | 19 In addition to explaining how to apply and revert patches, a brief
21 their specific patches) is also provided.
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
220 step. The -z flag to interdiff will even let you feed it patches in gzip or
232 downloading and applying of patches (https://www.selenic.com/ketchup/).
241 Where can I download the patches?
[all …]
|
| H A D | email-clients.rst | 11 end, maintainers use ``git am`` to apply the patches.
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
69 patches for the Linux kernel. These are not meant to be complete
[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,
81 up patches is a bit of an art; some developers spend a long time figuring
[all …]
|
| /openbmc/linux/Documentation/translations/zh_CN/process/ |
| H 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>`
|
| /openbmc/linux/Documentation/translations/zh_TW/process/ |
| H 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>`
|
| /openbmc/openbmc/meta-security/meta-tpm/ |
| H A D | README.md | 60 Send pull requests, patches, comments or questions to yocto-patches@lists.yoctoproject.org
62 When sending single patches, please using something like:
63 'git send-email -1 --to yocto-patches@lists.yoctoproject.org --subject-prefix=meta-security][PATCH'
67 $ git config sendemail.to yocto-patches@lists.yoctoproject.org
70 Now you can just do 'git send-email origin/master' to send all local patches.
|
| /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/openbmc/poky/meta/lib/oe/ |
| H A D | patch.py | 77 self.patches = []
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:
229 self.patches.insert(i, patch)
261 bb.note("patches is %s" % self.patches)
263 for i in self.patches:
[all …]
|
| /openbmc/linux/Documentation/livepatch/ |
| H 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.
|
| /openbmc/openbmc/meta-arm/ci/ |
| H A D | patchreview | 66 def patchreview(patches): argument
77 for patch in patches:
240 patches = []
243 patches += [os.path.join(directory, f) for f in filenames]
244 return patches
256 patches = gather_patches(args.dirs) variable
257 results = patchreview(patches)
|
| /openbmc/openbmc/meta-security/meta-hardening/ |
| H A D | README.md | 67 Send pull requests, patches, comments or questions to yocto-patches@lists.yoctoproject.org
69 When sending single patches, please using something like:
70 'git send-email -1 --to yocto-patches@lists.yoctoproject.org --subject-prefix=meta-hardening][PATCH'
74 $ git config sendemail.to yocto-patches@lists.yoctoproject.org
77 Now you can just do 'git send-email origin/master' to send all local patches.
|
| /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/openbmc/poky/scripts/contrib/ |
| H A D | patchreview.py | 56 def patchreview(patches): argument
68 for patch in patches:
226 patches = []
229 patches += [os.path.join(directory, f) for f in filenames]
230 return patches
250 patches = gather_patches(layers) variable
251 results = patchreview(patches)
|
| /openbmc/linux/drivers/scsi/aic7xxx/aicasm/ |
| H 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 …]
|
| /openbmc/u-boot/doc/driver-model/ |
| H A D | MIGRATION.txt | 14 The subsystem itself has been converted and maintainers should submit patches
25 and maintainers should submit patches switching over to using CONFIG_DM_USB and
35 and maintainers should submit patches switching over to using CONFIG_AHCI and
55 Board Maintainers should submit the patches for enabling DM_SPI and DM_SPI_FLASH
96 submit patches switching over to using CONFIG_DM_PCI and other base driver
105 should submit patches switching over to using CONFIG_DM_VIDEO and other base
|
| /openbmc/openbmc/poky/meta/lib/patchtest/ |
| H A D | mbox.py | 56 self.patches = [Patch(message) for message in mbox]
58 assert self.patches
59 self.patch_count = len(self.patches)
74 match = pattern.search(self.patches[0].subject)
|
| /openbmc/openbmc-tools/ |
| H A D | README.md | 20 ## Sending patches
22 Please use gerrit for all patches to this repository:
30 ## What we will do once we have your patches
32 So long as your patches look sane with a cursory glance you can expect them to
36 ## What you must have in your patches
|
| /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/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
|