a reminder to PR submitters

Ceri Davies setantae at submonkey.net
Thu Oct 23 04:27:46 PDT 2003


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.
> 
> >> (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.

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 list;
follow-ups set accordingly.

Ceri

-- 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20031023/cb8d4225/attachment.bin


More information about the freebsd-ports mailing list