From owner-freebsd-doc@FreeBSD.ORG Sun Nov 21 03:03:35 2004 Return-Path: Delivered-To: freebsd-doc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6217C16A4CE; Sun, 21 Nov 2004 03:03:35 +0000 (GMT) Received: from mail.soaustin.net (mail.soaustin.net [207.200.4.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id A1F6643D4C; Sun, 21 Nov 2004 03:03:34 +0000 (GMT) (envelope-from linimon@lonesome.com) Received: by mail.soaustin.net (Postfix, from userid 502) id 2CB2B148E9; Sat, 20 Nov 2004 21:03:34 -0600 (CST) Date: Sat, 20 Nov 2004 21:03:34 -0600 (CST) From: Mark Linimon X-X-Sender: linimon@pancho To: freebsd-doc@FreeBSD.org, Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: CFD: patches to the Handling PR Guidelines article X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Nov 2004 03:03:35 -0000 This patch does the following: - adds text about handling unassigned PRs - adds text about default assignees and common assignees (specifically to address the continuing confusion about assigning to mailing lists vs. assigning to aliases) - adds more text about how misfiled PRs occur - adds more text about how to kill spam PRs. This patch does not: - include any of the proposed elaborations on when a PR is stale. Unless someone objects, I plan to commit in the next day or so. mcl Index: article.sgml =================================================================== RCS file: /home/FreeBSD/dcvs/doc/en_US.ISO8859-1/articles/pr-guidelines/article.sgml,v retrieving revision 1.17 diff -u -r1.17 article.sgml --- article.sgml 8 Aug 2004 13:43:56 -0000 1.17 +++ article.sgml 21 Nov 2004 02:55:01 -0000 @@ -233,6 +233,9 @@ + PRs not yet assigned to someone. + + PRs already assigned to someone. @@ -250,6 +253,208 @@ PRs is used for, when a PR belongs to one of these types, and what treatment each different type receives. +
+ Unassigned PRs + + When PRs arrive, they are initially assigned to a generic + (placeholder) assignee. These are always prepended with + freebsd-. The exact value for this default + depends on the category; in most cases, it corresponds to a + specific &os; mailing list. Here are some examples: + + + + Default Assignees + + + + Type + Categories + Default Assignee + + + + + + base system + bin, conf, gnu, kern, misc + freebsd-bugs + + + + architecture-specific + alpha, i386, ia64, powerpc, sparc64 + freebsd-<arch> + + + + ports collection + ports + freebsd-ports-bugs + + + + documentation shipped with the system + docs + freebsd-doc + + + + &os; web pages (not including docs) + www + freebsd-www + + + + standards compliance + standards + freebsd-standards + + + + JVM problems + java + freebsd-java + + + + advocacy efforts + advocacy + freebsd-advocacy + + +
+ + + Do not be surprised to find that the submitter of the + PR has assigned it to the wrong category. If you fix the + category, do not forget to fix the assignment as well. + (In particular, our submitters seem to have a hard time + understanding that just because their problem manifested + on an i386 system, that it might be generic to all of &os;, + and thus be more appropriate for kern. + The converse is also true, of course.) + + Certain PRs may be reassigned away from these generic + assignees by anyone. For assignees which are mailing lists, + please use the long form when making the assignment (e.g., + freebsd-foo instead of foo); + this will avoid duplicate emails sent to the mailing list. + + + Here is a sample list of such entities; it may + not be complete. Entries that have the short form are + aliases, not mailing lists. + + + + + + Common Assignees + + + + Type + Suggested Assignee + + + + + + problem with Linux or SVR4 emulation + emulation + + + + problem with the networking stack + freebsd-net + + + + problem with PicoBSD + freebsd-small + + + + problem with the ports framework + (not with an individual port!) + portmgr + + + + problem with the SCSI subsystem + freebsd-scsi + + + + problem with the sound subsystem + sound + + + + problem with the threads subsystem + freebsd-threads + + + + problem with sysinstall + freebsd-qa + + + + problem with the USB subsystem + freebsd-usb + + + + port which is maintained by gnome@FreeBSD.org + gnome + + + + port which is maintained by haskell@FreeBSD.org + haskell + + + + port which is maintained by kde@FreeBSD.org + kde + + + + port which is maintained by + openoffice@FreeBSD.org + freebsd-openoffice + + + + port which is maintained by perl@FreeBSD.org + freebsd-perl + + + + port which is maintained by x11@FreeBSD.org + freebsd-x11 + + +
+ + + Ports PRs which have a maintainer who is a ports committer + may be reassigned by anyone (but note that not every &os; + committer is necessarily a ports committer, so you cannot + simply go by the email address alone.) + + + For other PRs, please do not reassign them to individuals + (other than yourself) unless you are certain that the assignee + really wants to track the PR. This will help to avoid the + case where no one looks at fixing a particular problem + because everyone assumes that the assignee is already working + on it. + +
+
Assigned PRs @@ -366,6 +571,14 @@ header. + + A submitter sent a Cc: to a mailing list and someone + followed up to that post instead of the email issued by + GNATS after processing. The email to the list will fail to + have the category/PRnumber tracking tag. (This is why we + discourage submitters from doing this exact thing.) + + When completing the &man.send-pr.1; template, the submitter forgot to set the category or class of the PR to a proper @@ -373,6 +586,15 @@ + When completing the &man.send-pr.1; template, the submitter + set Confidential to yes. (Since we allow + anyone to mirror GNATS via cvsup, + our PRs are public information. Security alerts should + therefore not be sent via GNATS but instead via email to + the Security Team.) + + + It is not a real PR, but some random message sent to bug-followup@FreeBSD.org or freebsd-gnats-submit@FreeBSD.org. @@ -487,8 +709,8 @@ The email addresses that GNATS listens to for incoming PRs have been published as part of the FreeBSD documentation, have been announced and listed on the web-site. This means that - spammers found them. Every day several messages with - advertisements would reach GNATS which promptly files them all + spammers found them. Spam messages + that reach GNATS are promptly filed under the pending category until someone looks at them. Closing one of these with &man.edit-pr.1; is very annoying though, because GNATS replies to the submitter and @@ -503,11 +725,35 @@ All developers who have access to the FreeBSD.org cluster machines are encouraged to check for misfiled PRs and immediately close those that are spam mail. Whenever you close one of - these PRs it is also a good idea to set its category to - junk. Junk PRs are not + these PRs, please do the following: + + + + Set Category to junk. + + + + Set Confidential to no. + + + + Set Responsible to yourself (and not, e.g., + freebsd-bugs, which merely + sends more mail). + + + + Set State to closed. + + + + Junk PRs are not backed up, so filing spam mail under this category makes it obvious that we do not care to keep it around or waste disk - space for it. + space for it. If you merely close them without changing the + category, they remain both in the master database and in + any copies of the database mirrored through + cvsup.