From owner-freebsd-ports@FreeBSD.ORG Thu May 20 12:22:11 2004 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 840CB16A4CE for ; Thu, 20 May 2004 12:22:11 -0700 (PDT) Received: from smtp.unsam.edu.ar (smtp.unsam.edu.ar [170.210.48.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5318C43D2D for ; Thu, 20 May 2004 12:22:03 -0700 (PDT) (envelope-from fernan@iib.unsam.edu.ar) Received: from pi.iib.unsam.edu.ar (pi.iib.unsam.edu.ar [192.168.10.11]) by smtp.unsam.edu.ar (8.12.6/8.12.6) with ESMTP id i4KJPLv0063761; Thu, 20 May 2004 16:25:22 -0300 (ART) (envelope-from fernan@iib.unsam.edu.ar) Received: from pi.iib.unsam.edu.ar (localhost.iib.unsam.edu.ar [127.0.0.1]) by pi.iib.unsam.edu.ar (8.12.9p2/8.12.9) with ESMTP id i4KJ3m2h041205; Thu, 20 May 2004 16:03:52 -0300 (ART) (envelope-from fernan@iib.unsam.edu.ar) Received: (from fernan@localhost) by pi.iib.unsam.edu.ar (8.12.9p2/8.12.9/Submit) id i4KJ3gnl041204; Thu, 20 May 2004 16:03:42 -0300 (ART) (envelope-from fernan@iib.unsam.edu.ar) X-Authentication-Warning: pi.iib.unsam.edu.ar: fernan set sender to fernan@iib.unsam.edu.ar using -f Date: Thu, 20 May 2004 16:03:42 -0300 From: Fernan Aguero To: Mark Linimon Message-ID: <20040520190342.GB2784@iib.unsam.edu.ar> Mail-Followup-To: Mark Linimon , FreeBSD Ports References: <40ACCF16.80306@xbsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i cc: FreeBSD Ports Subject: Re: ports/66740: [MAINTAINER] security/f-prot-sig: update to 20040517 X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2004 19:22:11 -0000 +----[ Mark Linimon (20.May.2004 15:14): | | On Thu, 20 May 2004, Florent Thoumie wrote: | | > The Problem Report is marked non-critical with low priority. | > | > I think you should have used other choices. | | Speaking only for myself, I now completely ignore the values in | these fields, because they are are almost universally misused. | If you browse the PR database, you'll be stunned by what people | consider to be critical and high priority. Once upon a time, I was a beginner FreeBSD user. And while trying to cooperate, I was told to read about how to send PRs, so I read the man page for send-pr(1). This gave me a good idea of what was expected for some of the fields of the PR but there was no clear explanation of the priority and severity fields. I reasoned then that it was because they should be obvious. However, as it is now clear to me, this is not the case. The description of a problem as 'non-critical, serious or critical' will always be subjective. And lacking any other context, the user is left to wonder 'critical with respect to what? to the operating system? to the ports collection? to other dependent ports? to me as an end user? I think that the problem that we are addressing here is a problem of lack of documentation and user education. I think that updating the documentation first and telling the users to read it is a good first step to solve this issue. Of course it will take time, but IMO, this is the way to go. Now, when talking about updating the documentation to reflect this (setting a policy on the use of 'severity' and 'priority fields), the problem is that this should be done specifically for each of the categories listed in send-pr(1), since obviously something that is critical for 'doc' would certainly not be considered as such in 'ports' or 'bin'. So, if we all agree, we can discuss in the list some examples that could be considered 'critical', 'serious' and 'non-critical' for 'ports' and then proceed to document them somewhere, perhaps updating or extending this article: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/problem-reports/index.html | | The last time we discussed these fields I was of the opinion that | we should try to get people to use these fields correctly. But | having seen that there are hundreds, if not thousands, of PRs | with all manner of settings of these fields, I now have changed | my mind and think these fields should just be dropped. I'm not a committer, but I suspect that these fields should be useful, if used wisely. Based on my personal experience I can say that, at least for me, I've found the documentation about this pretty scarce. It has not been evident to me what is considered a critical documentation problem, a critical ports problem, etc. If I have learned something about sending PRs (you tell me) it was basically after reading lots of them on the list, but not from reading any documentation about it. So I think that perhaps the user education and documentation alternative should be explored with a little more emphasis, before deciding on dropping these fields. My $0.2. Sorry for the long post. Fernan | The only other choice would be to have someone go through and audit | them, but IMHO that effort in the PR database would be better | spent closing PRs than managing them. | | mcl | +----] -- F e r n a n A g u e r o http://genoma.unsam.edu.ar/~fernan