| Committer's Guide | ||
|---|---|---|
| Prev | ||
From now on, every new vendor release of that file will need to have patches merged in by hand.
From now on, every new vendor release of that file will need to have patches verified by hand.
The -j option does not work very well. Ask David O'Brien
<obrien@FreeBSD.org> for horror
stories.
To add a file onto a branch, simply checkout or update to the branch you want to add to and then add the file using cvs add as you normally would. For example, if you wanted to MFC the file src/sys/alpha/include/smp.h from HEAD to RELENG_6 and it does not exist in RELENG_6 yet, you would use the following steps:
Example 1. MFC'ing a New File
% cd sys/alpha/include
% cvs update -rRELENG_6
cvs update: Updating .
U clockvar.h
U console.h
...
% cvs update -kk -Ap smp.h > smp.h
===================================================================
Checking out smp.h
RCS: /usr/cvs/src/sys/alpha/include/smp.h,v
VERS: 1.1
***************
% cvs add smp.h
cvs add: scheduling file `smp.h' for addition on branch `RELENG_6'
cvs add: use 'cvs commit' to add this file permanently
% cvs commit
As well as including an informative message with each commit you may need to include some additional information as well.
This information consists of one or more lines containing the key word or phrase, a colon, tabs for formatting, and then the additional information.
The key words or phrases are:
| PR: | The problem report (if any) which is affected (typically, by being closed) by this commit. |
| Submitted by: | The name and e-mail address of the person that submitted the fix; for committers, just the username on the FreeBSD cluster. |
| Reviewed by: | The name and e-mail address of the person or people that reviewed the change; for committers, just the username on the FreeBSD cluster. If a patch was submitted to a mailing list for review, and the review was favorable, then just include the list name. |
| Approved by: | The name and e-mail address of the person or people that approved the change; for committers, just the username on the FreeBSD cluster. It is customary to get prior approval for a commit if it is to an area of the tree to which you do not usually commit. In addition, during the run up to a new release all commits must be approved by the release engineering team. If these are your first commits then you should have passed them past your mentor first, and you should list your mentor, as in ``username-of-mentor (mentor)''. |
| Obtained from: | The name of the project (if any) from which the code was obtained. |
| MFC after: | If you wish to receive an e-mail reminder to MFC at a later date, specify the number of days, weeks, or months after which an MFC is planned. |
| Security: | If the change is related to a security vulnerability or security exposure, include one or more references or a description of the issue. |
Example 2. Commit log for a commit based on a PR
You want to commit a change based on a PR submitted by John Smith containing a patch. The end of the commit message should look something like this.
... PR: foo/12345 Submitted by: John Smith <John.Smith@example.com>
Example 3. Commit log for a commit needing review
You want to change the virtual memory system. You have posted patches to the appropriate mailing list (in this case, freebsd-arch) and the changes have been approved.
... Reviewed by: -arch
Example 4. Commit log for a commit needing approval
You want to commit a change to a section of the tree with a MAINTAINER assigned. You have collaborated with the listed MAINTAINER, who has told you to go ahead and commit.
... Approved by: abc
Where abc is the account name of the person who approved.
Example 5. Commit log for a commit bringing in code from OpenBSD
You want to commit some code based on work done in the OpenBSD project.
... Obtained from: OpenBSD
Example 6. Commit log for a change to FreeBSD-CURRENT with a planned commit to FreeBSD-STABLE to follow at a later date.
You want to commit some code which will be merged from FreeBSD-CURRENT into the FreeBSD-STABLE branch after two weeks.
... MFC after: 2 weeks
Where 2 is the number of days, weeks, or months after which an MFC is planned. The weeks option may be day, days, week, weeks, month, months, or may be left off (in which case, days will be assumed).
In some cases you may need to combine some of these.
Consider the situation where a user has submitted a PR containing code from the NetBSD project. You are looking at the PR, but it is not an area of the tree you normally work in, so you have decided to get the change reviewed by the arch mailing list. Since the change is complex, you opt to MFC after one month to allow adequate testing.
The extra information to include in the commit would look something like
PR: foo/54321 Submitted by: John Smith <John.Smith@example.com> Reviewed by: -arch Obtained from: NetBSD MFC after: 1 month
people.FreeBSD.org is the same as freefall.FreeBSD.org. Just create a public_html directory. Anything you place in that directory will automatically be visible under http://people.FreeBSD.org/.
The mailing lists are archived under /g/mail which will show up as /hub/g/mail with pwd(1). This location is accessible from any machine on the FreeBSD cluster.
This, and other documents, can be downloaded from ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.
For questions about FreeBSD, read the documentation before contacting <questions@FreeBSD.org>.
For questions about this documentation, e-mail <doc@FreeBSD.org>.