Date: Wed, 22 Oct 2003 15:32:18 -0400 From: Adam Weinberger <adamw@FreeBSD.org> To: Mark Linimon <linimon@lonesome.com> Cc: freebsd-ports@FreeBSD.org Subject: Re: a reminder to PR submitters Message-ID: <20031022193218.GM96543@toxic.magnesium.net> In-Reply-To: <Pine.LNX.4.44.0310220135110.4822-100000@pancho> References: <Pine.LNX.4.44.0310220135110.4822-100000@pancho>
next in thread | previous in thread | raw e-mail | index | archive | help
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@vectors.cx >> http://www.vectors.cx magnesium.net << adamw@magnesium.net << http://www.magnesium.net/~adamw FreeBSD >> adamw@FreeBSD.org >> http://people.freebsd.org/~adamw #vim:set ts=8: 8-char tabs prevent tooth decay.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031022193218.GM96543>