ports/66740: [MAINTAINER] security/f-prot-sig: update to
fernan at iib.unsam.edu.ar
Thu May 20 12:22:11 PDT 2004
+----[ Mark Linimon <linimon at lonesome.com> (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'
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:
| 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.
| 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.
F e r n a n A g u e r o
More information about the freebsd-ports