Differences

This shows you the differences between two versions of the page.

--- githubpullrequests [2017/03/01 00:44] – WarnerLosh
+++ githubpullrequests [2017/03/01 21:00] (current) – Add notes (as used by svn2git) to remote example EdMaste
@@ Line 1: / Line 1: @@
-====== Github Pull Request Policy ======
+Here's a rough outline of the %%FreeBSD%%'s de-facto policies towards github pull requests. They represent an alternate way to submit mature, ready to commit patches.
   * Github pull requests should be made for mature code that's ready to commit. The pull request should include a description of the problem being solved as well as a commit message that meets the %%FreeBSD%% project's standards.
-  * Github pull requests should not be used for discussion. If you'd like to use github as a tool to discuss changes, you can do that with your own private account.
+  * Code that still needs discussion or consensus building is not ready to submit as a pull request. Discussions and consensus building should happen in the appropriate project mailing list.
-  * Incomplete code that's submitted may be converted into a bugzilla request that the discretion of the project. When nobody can be found to review the change, it will be converted to a bugzilla request. When the domain experts would rather work with another tool, a pull request will be converted to that other tool.
+  * Github pull requests to the project should not be used for discussion. Please user your individual account for that, as appropriate.
-  * Pull requests older than 18 months will be converted to bugzilla items to not lose them.
+  * Before making non-trivial changes to %%FreeBSD%%, communicating with the appropriate mailing list or domain expert is encouraged. Pull requests should note anybody you've worked with in the project to review pull requests.
-  * When making pull requests that are non-trivial (trivial changes include adding new devices to a driver, fixing spelling, correcting minor bugs in non-critical systems), it's strongly recommended that the domain experts be sought out to review and take ownership of the request.
+  * Pull requests that are for third party software should be submitted upstream first.
-  * Pull requests that are for software include in %%FreeBSD%% that have upstream sources should be submitted there first. Incorrectly submitted changes will receive a redirect and closed.
+  * If there's a code review in Phabricator, it takes precedence over the pull request. Even after the fact. If the consensus is 'no' in the review, the change won't be pulled. If the change is pulled and it's pointed out a Phabricator that rejected it was overlooked, the change will be backed out.
-  * Best Effort Only. The project will make efforts to look at the pull requests from time to time. We make no timeliness guarantees at this time. Github pull requests remain an experimental feature of the project and may not get the time and attention of more mature efforts. If the submitter doesn't hear anything in a timely fashion, they are encouraged to solicit reviews or feedback from the appropriate mailing list.
+  * Any pull request that isn't ready to go into the tree may be closed. Best effort attempts to redirect to Bugzilla or a more appropriate location may be made.
+  * Stale requests may be closed with a request for rebase and a new pull request.
+  * This is a best effort only service. The project will try make efforts to resolve pull requests from time to time. We make no timeliness guarantees at this time. Github pull requests remain an experimental feature of the project and may not get the time and attention of more mature efforts. If the submitter doesn't hear anything in a timely fashion, they are encouraged to solicit reviews or feedback from the appropriate mailing list.
+Subject to change in the future as resources change and new tooling is created. Please see the %%FreeBSD%% handbook for information on Bugzilla, Phabricator and our code submission standards.
+===== Fetching pull requests into local repo =====
+To include pull requests when fetching add the following entry to the appropriate remote config in .git/config: ''%%fetch = +refs/pull/*/head:refs/remotes/upstream/pr/*%%''
+For example, the full remote entry may look like:
+<code>
+[remote "upstream"]
+        url = https://github.com/freebsd/freebsd
+        fetch = +refs/heads/*:refs/remotes/upstream/*
+        fetch = +refs/notes/*:refs/notes/*
+        fetch = +refs/pull/*/head:refs/remotes/upstream/pr/*
+</code>
+After fetching from this remote, individual pull requests can be examined with commands like ''%%git show upstream/pr/104%%'' or ''%%git log ..upstream/pr/104%%''.