a reminder to PR submitters

[Adam Weinberger]

I'm cc'ing this to freebsd-doc and Ceri, resident bugmeister, as their
input in this is important.

>> (10.22.2003 @ 0242 PST): Mark Linimon said, in 0.9K: <<
> Please do not set the Confidential field on your PRs to "yes".
> We really don't have a mechanism to deal with confidential
> PRs in GNATS due to the fact that the database itself can be
> replicated, via cvsup, to anyone's machine, and thus itself is
> inherently insecure.  Setting this field to "yes" merely makes
> your PR disappear into this limbo-category called "pending" which
> is dark and scary and filled with big spiders and stuff :-)
>> end of "a reminder to PR submitters" from Mark Linimon <<

There are a number of fields within GNATS that mean things to us (the
committers) that don't make sense to submitters, and there are fields
that have no use for us whatsoever.

Confidential
	This field is, as you have pointed out, useless to us, and
	simply causes the PR to disappear. The field should be removed
	from the send-pr interface, or some mechanism for handling
	confidential PRs should be introduced. I suggest the former.
Severity/Priority
	These are relatively redundant, and are simply mechanisms for
	people to artificially elevate the position of the PR in the
	search lists -- which, in my experience, causes them to be seen
	LAST.
Class
	Seriously. The classes in here make sense to us, because we're
	used to dealing with them. For ports, we need fields that
	indicate the following:
		* update/upgrade
		* fix/new functionality
		* error report
		* other
Submitter-Id
	"current-users" doesn't mean a thing. Submitter-Id should be
	usable as "user" or "maintainer," depending upon who submits the
	PR. If a maintainer wishes to submit a PR for an update to a
	port she maintains, she should be able to choose
	Class:update/upgrade, and Submitter-Id:maintainer.

Additionally, text should be added to the bracketed text in the blank
send-pr template indicating the use of each section for docs/ports/www
PRs:
Description
	<precise description of the problem (multiple lines)>
	<for new ports, description of application>
Fix
	<how to correct or work around the problem, if known (multiple lines)>
	<shar of new port, diffs for port/documentation updates>

You know, stuff like that. These things can help make send-pr(1) a more
usable tool.

# Adam


--
Adam Weinberger
vectors.cx	>>  adam at vectors.cx	>>  http://www.vectors.cx
magnesium.net	<<  adamw at magnesium.net	<<  http://www.magnesium.net/~adamw
FreeBSD		>>  adamw at FreeBSD.org	>>  http://people.freebsd.org/~adamw
#vim:set ts=8: 8-char tabs prevent tooth decay.