Important: handling commit interactions with bug database
hartmans at MIT.EDU
Tue Sep 17 16:50:00 EDT 2002
Hi. I've just deployed the integration between the RT bug tracking
system and our CVS repository.
Per previous discussion, we're moving to a model where any non-trivial
functionality change needs to be accompanied by a ticket open in the
bug database. This will allow us to generate better release notes.
To accomplish this we have created a syntax for manipulating tickets
along with commits. If you are someone who has commit access but is
not at MIT your commits MUST create or update a ticket.
To manipulate tickets you add some header lines to the top of your log
message. The lines can be of the form header: value or rt-header:
value. I'll show them without the rt-prefix.
Updating a ticket
To update a ticket, you include a
ticket: or rt-ticket: line in your log. For example:
Return errno not retval when getpeername fails.
By default when you update a ticket:
* the ticket it assigned to you
* The ticket it closed
If these defaults are not appropriate for your action you can override
them; see below.
Creating a ticket
You can also create a ticket at the same time as you commit. All you
have to do is use new instead of a ticket number in a ticket line.
However you almost certainly want to at least set the subject.
subject: Add AES support
Add an implementation of AES to libk5crypto.
In addition to closing the ticket and marking you as the owner of a
ticket, creating a new ticket makes you the requestor of the ticket.
OTher Things to Change
The following additional commands are supported:
* subject: changes the subject of ticket
* status: [open|resolved|new|stalled]
* owner: [username|nobody]
* cc: [email address]
* Component: change component of ticket [krb5-libs etc]
* Tags: [enhancement|nochange|noresource]
You could set version_fixed, but it is wrong to do so.
Also, note that you can update multiple tickets in one log message;
updates apply to the most recent ticket: command.
More information about the krbdev