On 2007 April 4, OGB representatives Alan Coopersmith & Stephen Lau met
with the BugTraq team to talk about external mail notifications and how
we could expose more information. The problem currently is that
external email addresses added to the 'Interest' list of a bug see an
extremely filtered view that is overly restrictive, especially when
compared to the view obtained via bugs.opensolaris.org (b.o.o.) which
exposes considerably more information.
(see CR 6488448 bugs.opensolaris.org interest-list notifications are
worse than useless)
The meeting's agenda was to determine what bug product/categories could
be exposed, and if exposed - what fields should be published.
It was decided that, due to other boundary mechanisms that publish bug
information, that the more-"open"/unfiltered-notifications should be an
opt-in feature, with the initial product just being "solaris". Other
product groups can choose to turn on this feature as they see fit.
Most of the fields were discussed, and it was decided that the ones
appropriate for publication were:
CR ID, Synopsis, Product/Cat/Subcat, Type/Subtype, Status/Substatus,
Priority, Description, Workaround, Targeted Release (including "Commit
to Fix in Build", "Fixed in Build", "Integrated in Build", and "Verified
in Build"), See Also, Duplicate of, Keywords, SR Product/Release/OS, SR
Impact, SR Severity, Introduced in Release/Build, and Root Cause.
Fields discussed as not being appropriate for publication were:
Evaluation, & Comments - both fields tend to contain confidential or
proprietary information. There was some discussion that we have had a
notice that Evaluation should not contain confidential information for
years now - and that we should work on opening this field (either
through the use of explicitly tagging a bug as Evaluation-publishable
via a keyword, or doing a product/cat filter). But in the interest of
making the next Bugster release (in April), Evaluation will be pushed
back and revisted for the next quarterly release (August).
SR HW - tends to contain proprietary platform names that Systems might
not want released.
Responsible Engineer - They're uncomfortable allowing names to be
published. They acknowledged that we publish this via b.o.o., but this
is a change that would affect multiple boundary systems - not just
b.o.o.; and that since this was available via b.o.o., it wouldn't be a
stopper. They offered to publish "Assigned status" (binary value: yes
or no) instead, which we agreed is minimally required.
cheers,
steve
--
stephen lau // stevel at sun.com | 650.786.0845 | http://whacked.net
opensolaris // solaris kernel development
