- Add subsection about the anomaly solving process

- Fix example about how to document C++ classes
- Fix note about non-const static class members


git-svn-id: svn://svn.gna.org/svn/sgpemv2/trunk@297 3ecf2c5c-341e-0410-92b4-d18e462d057c
This commit is contained in:
tchernobog 2006-02-07 12:25:55 +00:00
parent 8f02d11b0a
commit f8be22e03d
1 changed files with 64 additions and 11 deletions

View File

@ -97,6 +97,11 @@ Free Documentation License''.
@table @strong @table @strong
@item 2006, February 7th, @r{--- Matteo Settenvini}
Added subsection about the anomaly solving process.
Fixed C++ code conventions about how to document classes,
and the note about static non-const members in classes.
@item 2006, February 2nd, @r{--- Luca Vezzaro} @item 2006, February 2nd, @r{--- Luca Vezzaro}
Updated coding style with a point on static non-POD Updated coding style with a point on static non-POD
objects. objects.
@ -442,20 +447,24 @@ These are used @strong{before} reaching a resolution:
@item UNCONFIRMED @item UNCONFIRMED
This bug has recently been added to the database. Nobody has validated that This bug has recently been added to the database. Nobody has validated that
this bug is true. Users who have the "canconfirm" permission set may confirm this bug is true. The manager will usually confirm this bug, changing its state
this bug, changing its state to @samp{NEW}. Or, it may be directly resolved to @samp{NEW}, but in case the bug existance is quite clear, any stakeholder
and marked @samp{RESOLVED}. can mark it as such.
The anomaly may be marked also @samp{RESOLVED} by the manager, if it is
@samp{INVALID}, @samp{DUPLICATE} or so on, but @strong{not}
@samp{RESOLVED FIXED}.
@item NEW @item NEW
This bug has recently been added to the assignee's list of bugs and must be This bug has recently been added to the assignee's list of bugs and must be
processed. Bugs in this state may be accepted, and become @samp{ASSIGNED}, processed. Bugs in this state may be accepted, and become @samp{ASSIGNED},
passed on to someone else, and remain @samp{NEW}, or resolved and marked passed on to someone else, and remain @samp{NEW}, or it can be
@samp{RESOLVED}. made also @samp{RESOLVED}.
@item ASSIGNED @item ASSIGNED
This bug is not yet resolved, but is assigned to the proper person. From here This bug is not yet resolved, but is assigned to the proper person. From here
bugs can be given to another person and become @samp{NEW}, or resolved and bugs can be given to another person and become @samp{ASSIGNED} with a different
become @samp{RESOLVED}. assignee, or resolved and become @samp{RESOLVED}.
@item REOPENED @item REOPENED
This bug was once resolved, but the resolution was deemed incorrect. For example, This bug was once resolved, but the resolution was deemed incorrect. For example,
@ -552,6 +561,48 @@ Usually it's the same person as the assignee.
@end table @end table
@c % ----- new subsection
@subsection Roles solving anomalies
When solving an anomaly, we mostly follow the pattern therein explained:
@enumerate
@item
@b{Anybody}, having any role, can report an anomaly about the work done by someone else.
It doesn't make a lot of sense reporting a bug about what you're doing: you just
fix it and carry on.
It may be sensible to report problems about your work only if you discover them
in a second moment, when you don't cover the same role anymore, so the assignee
would be different by the reporter.
@item
The discussion starts. Usually the verifier will check the anomaly exists, but
if enough people confirm the bug, the @b{manager} can decide to mark the bug as
@samp{NEW} as well.
@item
Once it is clear who's the responsible for fixing the anomaly, the @b{manager}
assign the bug to them, marking it as @samp{ASSIGNED}.
@item
A fix/patch may come up from different sources, even by the reporter,
but only the @b{assignee} can apply it to the tree and mark the bug as
@samp{SOLVED}. They take full responsability of the fix.
@item
The @b{verifier} does the needed @acronym{QA,Quality Assurance}, and then either
reopens the bug or marks it as @samp{VERIFIED}.
@item
When and only if the product ships, a @samp{VERIFIED} anomaly may
become @samp{CLOSED}, by hand of the @b{manager}.
@end enumerate
@c % -------------------------------------------------- @c % --------------------------------------------------
@node Coding style, Committing changes, Writing documentation, Top @node Coding style, Committing changes, Writing documentation, Top
@ -725,8 +776,10 @@ Put incomplete class declarations before their interface,
documenting it. For example: documenting it. For example:
@example @example
@verbatim @verbatim
//! I'm a useless class /** \brief I'm a useless class
/** This class is completely useless. */ *
* This class is completely useless.
*/
class C; class C;
// [...] // [...]
@ -744,7 +797,7 @@ follow a common model. Try to adhere to it
by looking at existing headers. Document them by looking at existing headers. Document them
fully, even if it is tedious, using a fully, even if it is tedious, using a
Doxygen-like syntax. The payback will be Doxygen-like syntax. The payback will be
high, I assure you. high, we assure you.
@item @item
Class names are composed of UpperCamelCase words. Class names are composed of UpperCamelCase words.
@ -948,7 +1001,7 @@ Please follow this order when declaring a class interface:
Variable data members Variable data members
@end enumerate @end enumerate
Static non-const data members shouldn't exist. Static non-const public data members shouldn't exist.
Nested classes go declared @strong{outside} their Nested classes go declared @strong{outside} their
containing class. For example: containing class. For example:
@example @example