Initial draft of goals and use cases for debbugs
Hi,
As an exercise, given that Adam Heath asked for a potential redesign
of the system, I have decided to indulge in a little modeling of the
desired system.
Designs should be iterative, and need the input of all
participants. I'm merely trying to prime the pump here. Feel free to
add to the lists below, or tell me to prune from it. (This still
needs a lot of work)
======================================================================
Goals of the system
We are trying to implement a bug tracking system. This system
is where we file details of bugs reported by users and developers,
track the progress of the problem as actions are taken through the
life time of the problem. The Problem is associated with usually with
a package, and may be specific to a particular version of the
package, or a specific architecture, or an kernel, and the status of
the report may move through a set of known states.
[I need help elaborating/clarifying the definition here]
In no particular order.
(o) The system should present a library so that one would be able to
exercise the functionality (use cases) of the system
programmatically.
(o) The code should be modular and extensible
(o) The functionality of the current system should not be lost
(o) The current interfaces to the system should not be changed
(o) The system should be able to generate reports and statistics
about the system, based on various criteria
(o) The BTS should allow people to subscribe to bugs, bugs fdor a
package, bugs for a maintainer, or indeed, any of the meta data
associated with bugs [[I would love to be on the grave,
critical, serious bugs list near release time]].
Additional filters, like changes
(o) A bug has meta-data associated with it. Some examples are:
- categorization of the bug, with varying degrees
- packages, and version(s) the bug is associated with (default all
versions, unless specified otherwise?). [[Is this a good
idea? should we have a bug associated with multiple packages?
What should closure semantics be? Any closure closes the bug
for all packages? Or should each package need to individually
close the bug? Mass reposrts would never be needed with the
latter semantics]
- architectures
- kernel type GNU/{Hurd, BSD, Linux}
- Release critical
- distributions affected (Sid, testing, 3.0, etc)
- Humans who are associated with this bug
reporter, maintainer(s), people subscribed to this bug
- descriptive meta-date, like un-reproducible, more-info, help
- procedural metdata, like wontfix
- A bug has states associated with it open, forwarded, NMU fixed,
pending upload. etc
- A bug is related to other bugs (we could merge bugs, make a
bug be otherwise related or grouped with other bugs)
- one should be able to specify attachments and patches not
inlined with the report itself
(o) The list of meta-data attributes should be open and extensible
(o) The BTS should be able to handle MIME properly -- providing
links on ldap/HTTP, and attachments for NNTP/SMTP reports
(o) The BTS should be able to authenticate users,
(o) Some operations may require authorized users (resetting the
release critical flag is one that comes to mind).
======================================================================
======================================================================
Boundaries of the System
Since this is still modeling the use case modeling phase, we
should stick to the interactions of the users with the system, and
not internal interactions with the underlying machine. Not all
interaction methods may support all use cases (for example,
authentication may not be possible for some interfaces).
(o) The users should be able to interact with the system using email
(o) An HTTP interface to the system is desirable (perhaps readonly)
(o) An NNTP interface to the system is desirable (perhaps readonly)
(o) An LDAP interface to the system is desirable
(o) A CORBA interface to the system is desirable
(o) Local administrative interfaces to the BTS ???
======================================================================
======================================================================
Use cases
The current use cases should be easy enough to write down,
since they are implemented as atomic operations through
email.
* _User_ : send me information about a (list of)? Bug number(s)
* _User_ : send me information about a list of Bug numbers,
with boring details included
* _User_ : send me attached information for this bug
* _User_ : send me patches for this bug
* _Maintainer_ : send me a list of all my bugs
* _Reporter_ : send me a list of bugs submitted by me
* _User_ : send me a list of bugs for a list of maintainers
* _User_ : send me a list of bugs specific to the testing
distribution (these could be closed in Sid, maybe)
* _User_ : send me a list of bugs specific to <arch>
* _User_ : send me a list of bugs with severity serious
* _User_ : send me a list of bugs with severity > important
* _User_ : send me a list of bugs with the RC tag
* _User_ : send me a list of bugs with the Tag Name=X value=<spec>
* _User_ : send me a list of bugs which have been merged
* _User_ : send me a list of bugs which have been reopened
* _User_ : send me a list of bugs which have been forwarded
* _User_ : send me a list of bugs which have been forwarded to
an address matching a spec
* _User_ : send me a list of bugs opened in the last 3 days
* _User_ : send me a list of bugs closed in the last 3 days
* _User_ : send me a list of bugs with an attached patch
* _User_ : send me a list of bugs with status fixed in NMU
* _User_ : send me a list of bugs for a maintainers
matching a regular expression
* _User_ : send me a list of bugs with packages with name
matching a spec
* _User_ : send me a list of bugs with source package whose name
matches a spec
[these are just sample use cases which are a combination
of the above -- not listing all possible permutations ]
* _Maintainer_ : send me a list of all my bugs with severity > important
* _User_ : send me a list of bugs specific to the testing
distribution with severity > important
* _User_ : send me a list of bugs with severity > important and
with an attached patch
* _Admin_ : send me a list of all people who have reported bugs
(report_count >0)
* _Admin_ : send me a list of all people who have reported N bugs
* _Admin_ : send me a list of all people who have reported > N bugs
* _Admin_ : send me a list of all people who have reported > N
serious bugs
* _Admin_ : send me a list of all people who have reported bugs
and whose names match a spec
* _Admin_ : send me a list of all people who have reported bugs
and whose names match a spec
* _Admin_ : send me a list of all people who have subscribe to
bugs for packages matching a spec
* _Admin_ : send me a list of all people who have subscribe to
bugs for maintainers matching a spec
* _Admin_ : send me a list of all people who have subscribed to
our BTS whose names match a spec
* _User_ : send me a list of all maintainers with bugcount > 0
* _User_ : send me a list of all maintainers with bugcount = 12
* _User_ : send me a list of all maintainers with bugcount = MAXCOUNT
* _User_ : send me a list of all maintainers with more than 5
bugs of severity > 5
[ One could have combinations of the above clauses as well]
* _User_ : Change the email address associated with me
* _RM_ : set/reset the RC tag for a list of bug numbers
* _User_ : change the title of a bug
* _User_ : clone a bug
* _User_ : reassign a bug to Package=X
* _Maintainer_ : forward a bug to address <blah>
* _Maintainer_ : forward a bug to address <blah> with this email
* _Maintainer_ : unforward a bug
* _User_ : add tag to a bug
* _User_ : remove a tag from a bug
* _User_ : Subscribe to reports for a bug
* _User_ : Subscribe to reports for all bugs for a package
whose names matching a spec
* _User_ : Subscribe to reports for all bugs owned by a
maintainer whose name matches a spec
* _User_ : unsubscribe to reports for a bug
* _User_ : unsubscribe to reports for all bugs for a package
whose names matching a spec
* _User_ : unsubscribe to reports for all bugs owned by a
maintainer whose name matches a spec
* _User_ : change severity of a bug
* _User_ : add a package{list of versions} to a bug
* _User_ : remove a package{list of versions} from a bug (close
bugs?)
* _User_ : establish a relationship between a list of bugs
I am not quite sure where I am going with this
* _Maintainer_ : mark the bug fixed in version Y
* _Maintainer_ : set the list of versions a bug applies to
* _User_ : close the bug (user == maintainer or reporter?)
* _User_ : Open a bug report with package name(s)/version,
severity, and tags
* _User_ : Add a patch to the bug
* _User_ : add comments to a bug (or a list of bugs)
* _User_ : add external attachments to the bug
======================================================================
These are some example of functional interfaces that may
enable us to implement the use cases. Just thinking out loud.
(o) ShowBug #bugnumber [, #bugnumber ...] @Components
A _User_ can ask for the status for one or more bugs. The list of
components can change the amount of information returned -- elide
or include boring messages, include MIME attachemnets, etc.
Steps:
- The user makes a query specifying one or more BugIDs
- The system returns the information in a format dependent on the
interface.
variant: include (ValidateUser)
The user sends in authentication information
Steps:
- The user makes a query specifying one or more BugIDs
- (ValidateUser)[]
- The system returns the information in a format dependent on the
interface.
(o) ListBugs Limit @Components
A _User_ can ask for the summary of a set of bugs on the system
The Components could be a way to specify the amount of
information returned (Index only, {metadata. metadata} -- again,
I am thinking of LDAP here.
Steps:
- The user makes a query specifying zero or more limits For
example, limits can be None, packagename=spec,
maintainer=spec, metadata=value (like, severity=grave,
RCtag=Yes, distribution=Sid), or a complex format, like
LDAP queries.
- The system returns the information in a format dependent on the
interface.
variant: include (ValidateUser)
The user sends in authentication information as well
Steps:
- The user makes a query specifying zero or more limits
limits can be None, packagename=spec, maintainer=spec,
metadata=value (like, severity=grave, RCtag=Yes,
distribution=Sid)
- (ValidateUser)[]
- The system returns the information in a format dependent on the
interface.
(o) ListUsers Category @components
A _User_ can ask for the list of users from the system
The amount of detail returned depends on the components, and
the authorization requirements for each field.
General Steps:
- The user makes a query specifying zero or more category
For example, limits can be reporter/maintainer/other. Useful
limits can be category=maintainer && bug_count>0
- (ValidateUser)[]
- The system returns the information in a format dependent on the
interface.
(o) SetState #bugnumber [, #bugnumber ...] @options
A _User_ can ask for a change in the metadata of one or more bug
reports. The meta-data changed could be anything at all, so one
may change titles, close, forward, unforward, all using
this. depending on the options provided.
Steps:
-
(o) Clone #bugnumber
A _User_ can ask for a clone of a bug. The resulting bug is
then independent of the original
Steps:
-
======================================================================
Contributors:
David Schmitt
======================================================================
Booch, Rumbaugh, and Jacobson[1] state that one should consider
a design process that is
* Use case driven -- use cases are a primary artifact for
establishing the desired behaviour of the system, for verifying
and validating the systems's architecture, for testing, and for
communicating amongst the stakeholders for the project
* Architecture-centric -- the systems architecture is used as a
primary artifact for conceptualizing, constructing, managing, and
evolving the system under development.
* Iterative and incremental -- an iterative process is one that
involves managing a stream of releases [release early, often
.. ms]. An incremental process involves the continuous integration
of the system's architecture to produce these releases, with each
new release embodying incremental improvements over the other.
[1] Booch, Grady, Rumbaugh, James, Jacobson, Ivar "The Unified
Modeling Language User Guide", Addison Wesley
[2] Schneider, Geri, and Winters, Jason P. "Applying uUse Cases:
Apractical guide" Addison Wesley
--
Work continues in this area. DEC's SPR-Answering-Automaton
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-debbugs-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: