[prev in list] [next in list] [prev in thread] [next in thread] 

List:       opensolaris-tools-discuss
Subject:    Re: [tools-discuss] Draft DTS requirements, 3
From:       Stephen Hahn <sch () sun ! com>
Date:       2007-08-21 23:44:49
Message-ID: 20070821234448.GA17773 () eng ! sun ! com
[Download RAW message or body]

* Stephen Lau <stevel@opensolaris.org> [2007-08-20 17:55]:
> Stephen Hahn wrote:
> > (I'll go reread the Bugzilla thread from a couple of weeks ago, but if
> >  anyone wants to send me edits, I'll mention that 
> 
> I believe that thread was mostly text related to how Bugzilla meets the 
> requirements.  Rich had a comment on 8/16 re: substates that might be 
> worth incorporating:
> 
> >>Something I think is missing here is the granularity of bug states.
> >>Bugtraq/Bugster have 11 + substates on some, 
> >>
> >>bugzilla seems to have 4 or 5:
> >>  UNCONFIRMED, NEW, ASSIGNED, RESOLVED (+ substates), REOPENED
> >>
> >>This is lacking granularity (I assume the method with bugzilla is to
> >>push such such things as Cause Known into the comments?).
> >>
> >>I can't speak for any of the others (nor to whether it's possible to
> >>configure bugzilla in this regard).

  I've added a note to the evaluation section that the evaluator(s)
  should propose a correspondence.  

> >          E2.  Selective differentiated access
> >  
> >          A mechanism must exist to indicate that a defect is private to a
> >          set of Participants, and no part of it may be made accessible to
> >          Participants not in that set, even if the defect's subcategory
> >|         would otherwise cause it to be accessible.  (DTS Administrators
> >|         will have access to all defects.)
> 
> Should we define the role of what a DTS Administrator is?
 
  No; I think it's apparent.

> >|         E11.  Non-hierarchical defect classification
> >| 
> >|         Beyond E10, it appears that a candidate DTS should have one or
> >|         more free-form means of attaching classification information to
> >|         a defect.  Examples would include one or more keywords fields, a
> >|         set of name-value attributes, or a tagging facility.
> 
> Would said keywords/tags be unique within the hierarchical 
> classification, or global across the whole system?
> 
> Or is that a search parameter best left to the user?
 
  Global.  I've clarified E11.

> >  Otherwise, we can get onto candidate evaluation.
> 
> Yes. Let's.

  Diffs included below.

  - Stephen

----

diff -r 19e481fd99aa dts-requirements/d-dts-requirements.txt
--- a/dts-requirements/d-dts-requirements.txt	Mon Aug 20 14:45:40 2007 -0700
+++ b/dts-requirements/d-dts-requirements.txt	Tue Aug 21 16:41:55 2007 -0700
@@ -2,7 +2,7 @@ vim:set expandtab:
 vim:set expandtab:
 
 OpenSolaris
-DEFECT TRACKING SYSTEM REQUIREMENTS [DRAFT]
+DEFECT TRACKING SYSTEM REQUIREMENTS
 Stephen Hahn
 
 
@@ -285,8 +285,10 @@ 3.1.  "Essential" requirements
 
         Beyond E10, it appears that a candidate DTS should have one or
         more free-form means of attaching classification information to
-        a defect.  Examples would include one or more keywords fields, a
-        set of name-value attributes, or a tagging facility.
+        a defect.  This information should be attached such that, given
+        E9, a search involving the information could be performed across
+        the defect corpus.  Examples would include one or more keywords
+        fields, a set of name-value attributes, or a tagging facility.
 
         E12.  Concurrent change detection, basic
 
@@ -426,6 +428,11 @@ 3.1.  Representational and performance c
     - defects addressed in a given build/release
     - unresolved defects, ordered by importance
 
+    A report should propose, at least approximately, which of the
+    default classification schemes (E10, E11) can be utilized to
+    correspond to the legacy DTS's representation of defect
+    characteristics (such as states).
+
     The candidate DTS will be evaluated for data integrity by
     interruption of the set of operations by signal and by machine
     failure.
-- 
sch@sun.com  http://blogs.sun.com/sch/
_______________________________________________
tools-discuss mailing list
tools-discuss@opensolaris.org
[prev in list] [next in list] [prev in thread] [next in thread]