- 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:
parent
8f02d11b0a
commit
f8be22e03d
|
@ -97,6 +97,11 @@ Free Documentation License''.
|
|||
|
||||
@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}
|
||||
Updated coding style with a point on static non-POD
|
||||
objects.
|
||||
|
@ -442,20 +447,24 @@ These are used @strong{before} reaching a resolution:
|
|||
|
||||
@item UNCONFIRMED
|
||||
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, changing its state to @samp{NEW}. Or, it may be directly resolved
|
||||
and marked @samp{RESOLVED}.
|
||||
this bug is true. The manager will usually confirm this bug, changing its state
|
||||
to @samp{NEW}, but in case the bug existance is quite clear, any stakeholder
|
||||
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
|
||||
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},
|
||||
passed on to someone else, and remain @samp{NEW}, or resolved and marked
|
||||
@samp{RESOLVED}.
|
||||
passed on to someone else, and remain @samp{NEW}, or it can be
|
||||
made also @samp{RESOLVED}.
|
||||
|
||||
@item ASSIGNED
|
||||
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
|
||||
become @samp{RESOLVED}.
|
||||
bugs can be given to another person and become @samp{ASSIGNED} with a different
|
||||
assignee, or resolved and become @samp{RESOLVED}.
|
||||
|
||||
@item REOPENED
|
||||
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
|
||||
|
||||
@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 % --------------------------------------------------
|
||||
|
||||
@node Coding style, Committing changes, Writing documentation, Top
|
||||
|
@ -725,8 +776,10 @@ Put incomplete class declarations before their interface,
|
|||
documenting it. For example:
|
||||
@example
|
||||
@verbatim
|
||||
//! I'm a useless class
|
||||
/** This class is completely useless. */
|
||||
/** \brief I'm a useless class
|
||||
*
|
||||
* This class is completely useless.
|
||||
*/
|
||||
class C;
|
||||
// [...]
|
||||
|
||||
|
@ -744,7 +797,7 @@ follow a common model. Try to adhere to it
|
|||
by looking at existing headers. Document them
|
||||
fully, even if it is tedious, using a
|
||||
Doxygen-like syntax. The payback will be
|
||||
high, I assure you.
|
||||
high, we assure you.
|
||||
|
||||
@item
|
||||
Class names are composed of UpperCamelCase words.
|
||||
|
@ -948,7 +1001,7 @@ Please follow this order when declaring a class interface:
|
|||
Variable data members
|
||||
|
||||
@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
|
||||
containing class. For example:
|
||||
@example
|
||||
|
|
Loading…
Reference in New Issue