Lines Matching +full:pull +full:- +full:requests
1 <!--
4 SPDX-License-Identifier: curl
5 -->
28 notified of pull requests and new issues posted there.
60 [curl-library mailing list](https://curl.se/mail/list.cgi?list=curl-library)
69 [CODE_STYLE](https://curl.se/dev/code-style.html) already established in
75 ### Non-clobbering All Over
87 odd problems, but discussions and opinions do not agree with 10 of them - or 9
104 the most up-to-date sources from the git repository, but the latest release
136 Ideally you file a [pull request on
138 patch to [the curl-library mailing
139 list](https://curl.se/mail/list.cgi?list=curl-library).
142 it into a pull request for you, to have the CI jobs verify it proper before it
156 ## About pull requests
158 With GitHub it is easy to send a [pull
162 We strongly prefer pull requests to mailed patches, as it makes it a proper
167 Every pull request submitted is automatically tested in several different
173 try to update your pull requests to rerun the tests later as described below.
175 You can update your pull requests by pushing new commits or force-pushing
176 changes to existing commits. Force-pushing an amended commit without any
179 When you adjust your pull requests after review, consider squashing the
182 A pull request sent to the project might get labeled `needs-votes` by a
184 checks and qualifications this pull request must also receive more "votes" of
186 form of messages saying so, or thumbs-up reactions on GitHub.
188 ## When the pull request is approved
190 If it does not seem to get approved when you think it is ready - feel free to
193 Once your pull request has been approved it can be merged by a maintainer.
196 the pull request to be merged. This is typically a three week period that
197 starts ten days after a previous release. New features submitted as pull
198 requests while the window is closed simply have to wait until it opens to get
201 If time passes without your approved pull request gets merged: feel free to
210 to the list or better yet: change it to a pull request.
216 ---- start ----
218 -- empty line --
222 -- end --
227 - use the imperative, present tense: **change** not "changed" nor "changes"
228 - do not capitalize the first letter
229 - no period (.) at the end
240 - `Follow-up to {shorthash}` - if this fixes or continues a previous commit;
244 - `Bug: URL` to the source of the report or more related discussion; use
247 - `Approved-by: John Doe` - credit someone who approved the PR.
249 - `Authored-by: John Doe` - credit the original author of the code; only use
250 this if you cannot use `git commit --author=...`.
252 - `Signed-off-by: John Doe` - we do not use this, but do not bother removing
255 - `whatever-else-by:` credit all helpers, finders, doers; try to use one of
256 the following keywords if at all possible, for consistency: `Acked-by:`,
257 `Assisted-by:`, `Co-authored-by:`, `Found-by:`, `Reported-by:`,
258 `Reviewed-by:`, `Suggested-by:`, `Tested-by:`.
260 - `Ref: #1234` - if this is related to a GitHub issue or PR, possibly one that
263 - `Ref: URL` to more information about the commit; use `Bug:` instead for a
266 - `Fixes #1234` - if this fixes a GitHub issue; GitHub closes the issue once
269 - `Closes #1234` - if this merges a GitHub PR; GitHub closes the PR once this
272 Do not forget to use commit with `--author` if you commit someone else's work,
278 are using `--author` which hides your identity. Do not include people's email
286 repository instead of sending changes as pull requests or by mail as patches.
292 - [Webinar on getting code into cURL](https://www.youtube.com/watch?v=QmZ3W1d6LQI)
296 There is a CI job called **REUSE compliance / check** that runs on every pull
302 the `SPDX-License-Identifier` included. If the header does not work, you can
307 [REUSE helper tool](https://github.com/fsfe/reuse-tool): `reuse lint`