| /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
|
| H A D | submitting-a-pull-request.rst | 17 **Resend the patches with the pull request** as emails which are
35 people have reviewed the patches you're putting in the pull request,
36 make sure you've copied their signoffs across. (If you use the `patches
37 tool <https://github.com/stefanha/patches>`__ to add patches from email
39 you're updating patches manually or in some other way you'll need to
43 request says these patches are ready to go into QEMU now, so they must
|
| /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-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-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/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/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/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 …]
|
| H A D | patman | 34 default=-1, help='Automatically create patches from top n commits')
37 help='Send patches email even if patch errors are found')
44 default=False, help="Do a dry run (create but don't email patches)")
51 default=0, help='Commit to start creating patches from (0 = HEAD)')
68 default=False, help='Create patches as a single thread')
72 Create patches from commits in a branch, check them and email them as
129 # Process commits, produce patches files, check them, email them
134 # Work out how many patches to send if we can
156 # Check the patches, and run them through 'git am' just to be sure
166 # Email the patches out (giving the user time to check / cancel)
|
| H A D | patman.py | 34 default=-1, help='Automatically create patches from top n commits')
37 help='Send patches email even if patch errors are found')
44 default=False, help="Do a dry run (create but don't email patches)")
51 default=0, help='Commit to start creating patches from (0 = HEAD)')
68 default=False, help='Create patches as a single thread')
72 Create patches from commits in a branch, check them and email them as
129 # Process commits, produce patches files, check them, email them
134 # Work out how many patches to send if we can
156 # Check the patches, and run them through 'git am' just to be sure
166 # Email the patches out (giving the user time to check / cancel)
|
| /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/ |
| 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."
|
| H A D | patchtest.README | 5 Patchtest is a test framework for community patches based on the standard
14 openembedded-core repository [1], targeted for patches that get into the
19 which environment you prefer. If you plan to test your own patches (a
50 ### Obtaining Patches
53 format-patch -N` (where N is the number of patches starting from HEAD to
55 and timeboxes if specific patches are desired. For more information, see the
73 where N is the number of patches starting at HEAD, or by using git-pw
96 of isolation from the host when testing patches pulled automatically
108 2. Collect patches via patchtest-get-series (or other manual step) into the
146 When sending single patches, please use something like:
|
| /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/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-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/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/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/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/phosphor-host-ipmid/docs/ |
| H A D | contributing.md | 26 When pushing a stack of patches (current branch is >1 commits ahead of
29 So if one of the patches in the middle needs to be changed, all the patches from
31 effectively rebase the unchanged patches, which would in turn trigger a new CI
38 the paragraph above, when possible you should make changes to multiple patches
82 ## Sending Patches
84 Like most projects in OpenBMC, we use Gerrit to review patches. Please check the
97 have very deep review queues already of patches which have been waiting longer
108 The maintainers' job is to ensure that incoming patches are as correct and easy
|
| /openbmc/openbmc/meta-openembedded/meta-oe/ |
| H A D | README.md | 21 When sending single patches, please use something like:
25 to share your patches, this is preferred for patch sets consisting of more than one patch.
27 Note, it is discouraged to send patches via GitHub pull request system. Such
28 patches get less attention from developers and can be mishandled or not
|
| /openbmc/openbmc/poky/meta/lib/patchtest/tests/ |
| H A D | test_patch.py | 18 # get just those relevant patches: new software patches
35 # we are just interested in series that introduce CVE patches, thus discard other
40 self.skip('No new CVE patches introduced')
44 … self.skip("There are no new software patches, no reason to test Upstream-Status presence/format")
107 …self.skip("There are no new software patches, no reason to test %s presence" % PatchSignedOffBy.ma…
|