4. Writing the problem report

Now that you have decided that your issue merits a problem report, and that it is a FreeBSD problem, it is time to write the actual problem report. Before we get into the mechanics of the program used to generate and submit PRs, here are some tips and tricks to help make sure that your PR will be most effective.

4.1. Tips and tricks for writing a good problem report

4.2. Before you begin

If you are using the send-pr(1) program, make sure your VISUAL (or EDITOR if VISUAL is not set) environment variable is set to something sensible.

You should also make sure that mail delivery works fine. send-pr(1) uses mail messages for the submission and tracking of problem reports. If you cannot post mail messages from the machine you are running send-pr(1) on, your problem report will not reach the GNATS database. For details on the setup of mail on FreeBSD, see the “Electronic Mail” chapter of the FreeBSD Handbook at http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/mail.html.

Make sure that your mailer will not mangle the message on its way to GNATS. In particular, if your mailer automatically breaks lines, changes tabs to spaces, or escapes newline characters, any patch that you submit will be rendered unusable. For the text sections, however, we request that you insert manual linebreaks somewhere around 70 characters, so that the web display of the PR will be readable.

Similar considerations apply if you are using the web-based PR submission form instead of send-pr(1). Note that cut-and-paste operations can have their own side-effects on text formatting. In certain cases it may be necessary to use uuencode(1) to ensure that patches arrive unmodified.

Finally, if your submission will be lengthy, you should to prepare your work offline so that nothing will be lost in case there is a problem submitting it. This can especially be a problem with the web form.

4.3. Attaching patches or files

The following applies to submitting PRs via email:

The send-pr(1) program has provisions for attaching files to a problem report. You can attach as many files as you want provided that each has a unique base name (i.e. the name of the file proper, without the path). Just use the -a command-line option to specify the names of the files you wish to attach:

% send-pr -a /var/run/dmesg -a /tmp/errors

Do not worry about binary files, they will be automatically encoded so as not to upset your mail agent.

If you attach a patch, make sure you use the -c or -u option to diff(1) to create a context or unified diff (unified is preferred), and make sure to specify the exact SVN revision numbers of the files you modified so the developers who read your report will be able to apply them easily. For problems with the kernel or the base utilities, a patch against FreeBSD-CURRENT (the HEAD Subversion branch) is preferred since all new code should be applied and tested there first. After appropriate or substantial testing has been done, the code will be merged/migrated to the FreeBSD-STABLE branch.

If you attach a patch inline, instead of as an attachment, note that the most common problem by far is the tendency of some email programs to render tabs as spaces, which will completely ruin anything intended to be part of a Makefile.

Do not send patches as attachments using Content-Transfer-Encoding: quoted-printable. These will perform character escaping and the entire patch will be useless.

Also note that while including small patches in a PR is generally all right—particularly when they fix the problem described in the PR—large patches and especially new code which may require substantial review before committing should be placed on a web or ftp server, and the URL should be included in the PR instead of the patch. Patches in email tend to get mangled, especially when GNATS is involved, and the larger the patch, the harder it will be for interested parties to unmangle it. Also, posting a patch on the web allows you to modify it without having to resubmit the entire patch in a followup to the original PR. Finally, large patches simply increase the size of the database, since closed PRs are not actually deleted but instead kept and simply marked as closed.

You should also take note that unless you explicitly specify otherwise in your PR or in the patch itself, any patches you submit will be assumed to be licensed under the same terms as the original file you modified.

4.4. Filling out the template

The next section applies to the email method only:

When you run send-pr(1), you are presented with a template. The template consists of a list of fields, some of which are pre-filled, and some of which have comments explaining their purpose or listing acceptable values. Do not worry about the comments; they will be removed automatically if you do not modify them or remove them yourself.

At the top of the template, below the SEND-PR: lines, are the email headers. You do not normally need to modify these, unless you are sending the problem report from a machine or account that can send but not receive mail, in which case you will want to set the From: and Reply-To: to your real email address. You may also want to send yourself (or someone else) a carbon copy of the problem report by adding one or more email addresses to the Cc: header.

In the email template only, you will find the following single-line fields:

The next section describes fields that are common to both the email interface and the web interface:

Finally, there is a series of multi-line fields:

4.5. Sending off the problem report

If you are using send-pr(1):

Once you are done filling out the template, have saved it, and exit your editor, send-pr(1) will prompt you with s)end, e)dit or a)bort?. You can then hit s to go ahead and submit the problem report, e to restart the editor and make further modifications, or a to abort. If you choose the latter, your problem report will remain on disk (send-pr(1) will tell you the filename before it terminates), so you can edit it at your leisure, or maybe transfer it to a system with better net connectivity, before sending it with the -f to send-pr(1):

% send-pr -f ~/my-problem-report

This will read the specified file, validate the contents, strip comments and send it off.

If you are using the web form:

Before you hit submit, you will need to fill in a field containing text that is represented in image form on the page. This unfortunate measure has had to be adopted due to misuse by automated systems and a few misguided individuals. It is a necessary evil that no one likes; please do not ask us to remove it.

Note that you are strongly advised to save your work somewhere before hitting submit. A common problem for users is to have their web browser displaying a stale image from its cache. If this happens to you, your submission will be rejected and you may lose your work.

If you are unable to view images for any reason, and are also unable to use send-pr(1), please accept our apologies for the inconvenience and email your problem report to the bugbuster team at .