diff options
Diffstat (limited to 'documentation/content/en/articles/committers-guide/_index.adoc')
| -rw-r--r-- | documentation/content/en/articles/committers-guide/_index.adoc | 23 |
1 files changed, 17 insertions, 6 deletions
diff --git a/documentation/content/en/articles/committers-guide/_index.adoc b/documentation/content/en/articles/committers-guide/_index.adoc index d52aab2ee5..26bb41e98b 100644 --- a/documentation/content/en/articles/committers-guide/_index.adoc +++ b/documentation/content/en/articles/committers-guide/_index.adoc @@ -188,8 +188,7 @@ Rather than suggest a single way, here are some links to sites that describe var Protect the private key and passphrase. If either the private key or passphrase may have been compromised or disclosed, immediately notify mailto:accounts@FreeBSD.org[accounts@FreeBSD.org] and revoke the key. -Committing the new key is shown in crossref:committers-guide[commit-steps, Steps -for New Committers]. +Committing the new key is shown in crossref:committers-guide[commit-steps, Steps for New Committers]. [[kerberos-ldap]] == Kerberos and LDAP web Password for FreeBSD Cluster @@ -199,7 +198,6 @@ The Kerberos password also serves as the LDAP web password, since LDAP is proxyi Some of the services which require this include: * https://bugs.freebsd.org/bugzilla[Bugzilla] -* https://ci.freebsd.org[Jenkins] To create a new Kerberos account in the FreeBSD cluster, or to reset a Kerberos password for an existing account using a random password generator: @@ -834,8 +832,10 @@ To abort and get back to the state before "git rebase", run "git rebase --abort" Could not apply 646e0f9cda11... no color ls .... which looks scary. + If you bring up an editor, you will see it is a typical 3-way merge conflict resolution that you may be familiar with from other source code systems (the rest of ls.c has been omitted): [source,shell] +.... <<<<<<< HEAD #ifdef COLORLS_NEW #include <terminfo.h> @@ -845,7 +845,9 @@ If you bring up an editor, you will see it is a typical 3-way merge conflict res #include <termcap.h> >>>>>>> 646e0f9cda11... no color ls .... + The new code is first, and your code is second. + The right fix here is to just add a #undef COLORLS_NEW before #ifdef and then delete the old changes: [source,shell] .... @@ -854,6 +856,7 @@ The right fix here is to just add a #undef COLORLS_NEW before #ifdef and then de #include <terminfo.h> .... save the file. + The rebase was interrupted, so you have to complete it: [source,shell] .... @@ -1392,7 +1395,7 @@ Here 'good' means: . All the right files, and none of the wrong ones, were merged into contrib/glorbnitz. . No other changes are in the tree. . The commit messages look crossref:committers-guide[commit-log-message,good]. It should contain a summary of what's changed since the last merge to the FreeBSD `main` branch and any caveats. -. UPDATING should be updated if there is anything of note, such as user visible changes, important upgrade concerns, etc. +. `RELNOTES` and `UPDATING` should be updated if there is anything of note, such as user visible changes, important upgrade concerns, etc. [NOTE] ==== @@ -2481,15 +2484,16 @@ The subject should, by itself, allow the reader to quickly determine if the chan The subject line should be as short as possible while still retaining the required information. This is to make browsing Git log more efficient, and so that git log --oneline can display the short hash and subject on a single 80-column line. -A good rule of thumb is to stay below 63 characters, and aim for about 50 or fewer if possible. +A good rule of thumb is to stay below 67 characters, and aim for about 50 or fewer if possible. === Prefix the subject line with a component, if applicable If the change relates to a specific component the subject line may be prefixed with that component name and a colon (:). +If applicable, try to use the same prefix used in previous commits to the same files. ✓ `foo: Add -k option to keep temporary data` -Include the prefix in the 63-character limit suggested above, so that `git log --oneline` avoids wrapping. +Include the prefix in the 67-character limit suggested above, so that `git log --oneline` avoids wrapping. === Capitalize the first letter of the subject @@ -2649,6 +2653,10 @@ We include the commit title so that the referenced commit can be located even in |`Relnotes:` |If the change is a candidate for inclusion in the release notes for the next release from the branch, set to `yes`. +|Candidates are user-visible changes, new features, compatibility breaks, etc.. +|If you forget to set this line, or want to provide more details, add an entry to the `RELNOTES` file in the root of the src tree. +|The `RELNOTES` file is used to generate release notes for the next release. +|Do not use the `Relnotes:` line to describe the change: its only valid value is `yes`. |`Security:` |If the change is related to a security vulnerability or security exposure, include one or more references or a description of the issue. If possible, include a VuXML URL or a CVE ID. @@ -2972,6 +2980,9 @@ You can find out more about Bugzilla at: The FreeBSD Project utilizes https://reviews.freebsd.org[Phabricator] for code review requests. See the https://wiki.freebsd.org/Phabricator[Phabricator wiki page] for details. +Please use the `git arc` command provided by `devel/freebsd-git-devtools` (install the port or package, then type `git help arc` for documentation) to create and update Phabricator reviews. +This will make it easier for others to review and test your patches. + Committers with non-``FreeBSD.org`` Phabricator accounts can have the old account renamed to the ``FreeBSD.org`` account by following these steps: [.procedure] |