Date: Thu, 23 Oct 2003 12:27:37 +0100 From: Ceri Davies <setantae@submonkey.net> To: Adam Weinberger <adamw@FreeBSD.org> Cc: freebsd-ports@FreeBSD.org Subject: Re: a reminder to PR submitters Message-ID: <20031023112737.GD350@submonkey.net> In-Reply-To: <20031022193218.GM96543@toxic.magnesium.net> References: <Pine.LNX.4.44.0310220135110.4822-100000@pancho> <20031022193218.GM96543@toxic.magnesium.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--tNQTSEo8WG/FKZ8E Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 22, 2003 at 03:32:18PM -0400, Adam Weinberger wrote: > I'm cc'ing this to freebsd-doc and Ceri, resident bugmeister, as their > input in this is important. >=20 > >> (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 << >=20 > 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. >=20 > 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. These used to get spammed at core. Whether they still do is unknown to me at this point, but there was strong feeling that there wasn't much point in this. It would be pretty easy to remove it from send-pr if that's what people want. > 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. I'd recommend that committers correct the priorities to something more realistic when they deal with a PR. Other than that, I'm not sure what else we can do with these. > 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 I mailed portmgr on September 18th asking them if they'd be interested in something along these lines. No response yet. > 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. That's a good idea. > 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> That's also a good idea. I'd invite any further discussion to continue on the bugbusters@ mailing li= st; follow-ups set accordingly. Ceri --=20 --tNQTSEo8WG/FKZ8E Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQE/l7spocfcwTS3JF8RAtYqAJ49QRPxGW9MgH7pH8QyWZSnNBY/HACbB5Qi GLc/lUGbuI7oZIHNJseMmaI= =MOfL -----END PGP SIGNATURE----- --tNQTSEo8WG/FKZ8E--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031023112737.GD350>