![/!\](/moin_static1911/modern/img/alert.png "/!\"){kind=small}
This article is GNATS-specific and thus years out of date as of 2024.
Tips and Tricks
Tags
The "tag" convention is a complete hack. It is a prototype to allow us to think about how a real tool should let us classify PRs. In the database, we edit up the Synopses to include "[tagname]".
As a convention, we've started with the names of various src subsystems, as shown in subdirectories of the tree. Thus, the usb subsystem gets [usb], the re(4) driver gets [re], the NFS filesystem gets [nfs], and so forth. The use of [patch] or [panic] in addition to those is quite common.
Unfortunately, the websearch cgi script consumes literal '[' and literal ']' for its own nefarious purposes, so it's not currently possible to search by tag on the web page. This is a bug and we should try to fix it.
So, if you want to search on a tag, you need to do a little bit of workaround. For example, for usb, put the following into Text in single-line fields: "^.usb. " (note the trailing space).
This hack will serve until we can fix the bug.
(Note: if you are a FreeBSD developer and thus have access to GNATS, you can get the same result via "~gnats/tools/showwithtag usb").
Currently we are only using this convention for src PRs. For ports PRs, we don't normally use the [patch] convention, since our 'update' classification kind of subsumes that (and, often, the existance of a patch is implied in "update foo to version x.y"). For bin PRs, the convention used is e.g. "ls(1)". For doc PRs, the convention used is also "ls(1)" but probably ought to be "ls.1".
You can see the complete list of current tags via the "Current problem reports sorted by tag" posting (e.g. 20080121 posting).
the Severity and Priority fields
These fields have become totally meaningless over the years. End-users believe that somehow by setting higher values for these fields, that magically developer attention will be attracted to them. However, it's been a downward spiral, and now "everything" is important, and, as a result, nothing is important.
The invalid assumption here is that our developer-volunteers have any agenda other than their own. A few of our volunteers are sufficiently dedicated to prioritize things that they think will benefit the project in front of the neat stuff they want to work on, but if they aren't, there's really nothing anyone can do except ask nicely. Most volunteers have years worth of stuff that they _could_ work on, given enough time; since few people get paid, their rewards must be intrinsic, not extrinsic. There's no cudgel that we can hit them with if they don't want to work on a particular problem. (This is exacerbated by the wide range in quality of our incoming bug reports, including some that are "only fails now and then", "only fails on oddball hardware xyz", and so forth). We have to respect the right of all of our volunteers to spend as much, or as little, time on their priorities as they feel comfortable with. Anything else just leads to burnout and drives people away from FreeBSD.
So, don't get hung up on whether something has an allegedly higher Severity or Priority. Unless we go through and somehow vet all these things (an enormous task), they've just lost meaning.
Note: MarkLinimon believes there should be _some_ ratings along these lines, but what we have isn't it.