[Slony1-commit] slony1-www/content bug-processing.txt

Fri Aug 13 15:26:57 PDT 2010

Update of /home/cvsd/slony1/slony1-www/content
In directory main.slony.info:/tmp/cvs-serv28368/content

Modified Files:
	bug-processing.txt 
Log Message:
Tab things over - probably needed

Index: bug-processing.txt
===================================================================
RCS file: /home/cvsd/slony1/slony1-www/content/bug-processing.txt,v
retrieving revision 1.1
retrieving revision 1.2
diff -C 2 -d -r1.1 -r1.2
*** bug-processing.txt	13 Aug 2010 22:17:15 -0000	1.1
--- bug-processing.txt	13 Aug 2010 22:26:54 -0000	1.2
***************
*** 1,128 ****
  Bug Processing
  #
! <h1>Slony-I Bug Processing</h1>
! 	
! <p> Slony bug tracking is being managed using <a
! href="http://www.bugzilla.org/"> Bugzilla.</a></p>
! 	
! <p> Here is the <a href="http://www.slony.info/bugzilla/"> Slony-I
! Bugzilla Instance </a>.

! <h1> Bug Management Process </h1>

! <a href=
! "http://www.slony.info/bugzilla/docs/en/html/lifecycle.html"> Bug
! Lifecycle Documentation </a> uses the following image <img
! src="http://www.slony.info/bugzilla/docs/en/images/bzLifecycle.png">
! to characterize the flow of work on bugs, through various states, as
! they (hopefully!) get fixed.

! The following interpretations are suggested.

! <h2> NEW </h2>
! <a name="NEW">

! When a bug is created, it is created with NEW state, is
! assigned to <tt>slony1-bugs at lists.slony.info</tt>, and an email is
! sent to the bug tracking list.

! At this point, someone on the Slony development team should
! examine the bug to ascertain what, if anything, should be done with
! it.

! <P> It may be appropriate to:
! <ul>

! <li> Assign it to someone that is expected to work on it, changing the
! owner, and change the status to <a href="#ASSIGNED">ASSIGNED</A>.

! <li> Perhaps the bug is trivially resolved, in which case, it is
! reasonable to jump straight to marking it <a
! href="#RESOLVED">RESOLVED</a>.

! <li> Perhaps the bug is invalid. Jump straight to <a href=
! "#RESOLVED">RESOLVED</a>.

! <li> Perhaps it is unclear who should work on it. Perhaps the bug
! should be left alone, or perhaps it should be <a
! href="#ASSIGNED">ASSIGNED</A> to someone who might know who
! should do the work.

! </ul>

! <h2> ASSIGNED </h2>
!   <a name="ASSIGNED">

! This is the state of bugs that belong to someone. That
! someone should presumably be a human, and not
! <tt>slony1-bugs at lists.slony.info</tt>.

! <h2> RESOLVED </h2>
!   <a name="RESOLVED">

! This is the state of bugs that have been addressed, after some
! fashion.

! <P> There are several possible resolutions:
! <ul>
! <li> <B>FIXED</B> - believed to be resolved
! <li> <B>DUPLICATE</B> - this apparently duplicates some previous bug
! <li> <B>WONTFIX</B> - a problem that we don't plan to address
! <li> <B>WORKSFORME</B> - the developer can't duplicate the issue
! <li> <B>INVALID</B> - the problem is considered part of the proper behaviour of Slony
! </ul>

! Note that this is not the end of the lifecycle!

! If a developer has a patch for a complex issue, it is appropriate to:
! <ul>
! <li> Attach a patch, or perhaps a reference to a Git commit for the proposed fix.
! <li> Mark the bug RESOLVED/FIXED
! <li> Reassign the bug, either to:
! <ul>
! <li> The person that reported the bug
! <li> The <tt>slony1-bugs at lists.slony.info</tt> user
! <li> A specific Slony developer that is to validate the fix as <a name="#VERIFIED"> VERIFIED</a>
! </ul>

! <h2> VERIFIED </h2>
!   <a name="VERIFIED">

! A developer (or user) takes a <a href="#RESOLVED">RESOLVED</a> bug, and evaluates
! whether the resolution provided is proper.

! <P> The same resolution values apply:
! <ul>
! <li> <B>FIXED</B> - believed to be resolved
! <li> <B>DUPLICATE</B> - this apparently duplicates some previous bug
! <li> <B>WONTFIX</B> - a problem that we don't plan to address
! <li> <B>WORKSFORME</B> - the developer can't duplicate the issue
! <li> <B>INVALID</B> - the problem is considered part of the proper behaviour of Slony
! </ul>

! At this point, for complex patches, we can consider that the patch
! has been verified to be valid to be committed and released.

! The bug might be re-assigned back to the original developer to do
! the commit. But wait, it's not <a href="#CLOSED">CLOSED</a> yet...

! <H2> CLOSED </h2>
!   <a name="CLOSED">

! The final destination for a Slony bug is for it to be closed. The
! fix should have passed through phases of being <a href="#ASSIGNED">
! ASSIGNED</a> <a href="#RESOLVED"> RESOLVED</a> <a name="#VERIFIED">
! VERIFIED</a>. For particularly simple bugs, or for issues considered
! to not really be bugs, these phases may be rather brief.

! A bug being marked CLOSED should indicate that we have put
! it into some specific release, and placed a suitable reference into
! the release notes.

! <H2> REOPENED </h2>

! <P> Oh, no, the <b>zombie bug!</b>

! <P> Sometimes bugs aren't solved in the first attempt, and need to be
! reopened.  This is pretty much equivalent to <a href="#ASSIGNED">
! ASSIGNED</a>.
\ No newline at end of file
--- 1,128 ----
  Bug Processing
  #
! 		<h1>Slony-I Bug Processing</h1>
! 			
! 		<p> Slony bug tracking is being managed using <a
! 		href="http://www.bugzilla.org/"> Bugzilla.</a></p>
! 			
! 		<p> Here is the <a href="http://www.slony.info/bugzilla/"> Slony-I
! 		Bugzilla Instance </a>.

! 		<h1> Bug Management Process </h1>

! 		 <a href=
! 		"http://www.slony.info/bugzilla/docs/en/html/lifecycle.html"> Bug
! 		Lifecycle Documentation </a> uses the following image <img
! 		src="http://www.slony.info/bugzilla/docs/en/images/bzLifecycle.png">
! 		to characterize the flow of work on bugs, through various states, as
! 		they (hopefully!) get fixed.

! 		 The following interpretations are suggested.

! 		<h2> NEW </h2>
! 		<a name="NEW">

! 		 When a bug is created, it is created with NEW state, is
! 		assigned to <tt>slony1-bugs at lists.slony.info</tt>, and an email is
! 		sent to the bug tracking list.

! 		 At this point, someone on the Slony development team should
! 		examine the bug to ascertain what, if anything, should be done with
! 		it.

! 		<P> It may be appropriate to:
! 		<ul>

! 		<li> Assign it to someone that is expected to work on it, changing the
! 		owner, and change the status to <a href="#ASSIGNED">ASSIGNED</A>.

! 		<li> Perhaps the bug is trivially resolved, in which case, it is
! 		reasonable to jump straight to marking it <a
! 		href="#RESOLVED">RESOLVED</a>.

! 		<li> Perhaps the bug is invalid. Jump straight to <a href=
! 		"#RESOLVED">RESOLVED</a>.

! 		<li> Perhaps it is unclear who should work on it. Perhaps the bug
! 		should be left alone, or perhaps it should be <a
! 		href="#ASSIGNED">ASSIGNED</A> to someone who might know who
! 		should do the work.

! 		</ul>

! 		<h2> ASSIGNED </h2>
! 		  <a name="ASSIGNED">

! 		 This is the state of bugs that belong to someone. That
! 		someone should presumably be a human, and not
! 		<tt>slony1-bugs at lists.slony.info</tt>.

! 		<h2> RESOLVED </h2>
! 		  <a name="RESOLVED">

! 		 This is the state of bugs that have been addressed, after some
! 		fashion.

! 		<P> There are several possible resolutions:
! 		<ul>
! 		<li> <B>FIXED</B> - believed to be resolved
! 		<li> <B>DUPLICATE</B> - this apparently duplicates some previous bug
! 		<li> <B>WONTFIX</B> - a problem that we don't plan to address
! 		<li> <B>WORKSFORME</B> - the developer can't duplicate the issue
! 		<li> <B>INVALID</B> - the problem is considered part of the proper behaviour of Slony
! 		</ul>

! 		 Note that this is not the end of the lifecycle!

! 		 If a developer has a patch for a complex issue, it is appropriate to:
! 		<ul>
! 		<li> Attach a patch, or perhaps a reference to a Git commit for the proposed fix.
! 		<li> Mark the bug RESOLVED/FIXED
! 		<li> Reassign the bug, either to:
! 		 <ul>
! 		 <li> The person that reported the bug
! 		 <li> The <tt>slony1-bugs at lists.slony.info</tt> user
! 		 <li> A specific Slony developer that is to validate the fix as <a name="#VERIFIED"> VERIFIED</a>
! 		 </ul>

! 		<h2> VERIFIED </h2>
! 		  <a name="VERIFIED">

! 		 A developer (or user) takes a <a href="#RESOLVED">RESOLVED</a> bug, and evaluates
! 		whether the resolution provided is proper.

! 		<P> The same resolution values apply:
! 		<ul>
! 		<li> <B>FIXED</B> - believed to be resolved
! 		<li> <B>DUPLICATE</B> - this apparently duplicates some previous bug
! 		<li> <B>WONTFIX</B> - a problem that we don't plan to address
! 		<li> <B>WORKSFORME</B> - the developer can't duplicate the issue
! 		<li> <B>INVALID</B> - the problem is considered part of the proper behaviour of Slony
! 		</ul>

! 		 At this point, for complex patches, we can consider that the patch
! 		has been verified to be valid to be committed and released.

! 		 The bug might be re-assigned back to the original developer to do
! 		the commit. But wait, it's not <a href="#CLOSED">CLOSED</a> yet...

! 		<H2> CLOSED </h2>
! 		  <a name="CLOSED">

! 		 The final destination for a Slony bug is for it to be closed. The
! 		fix should have passed through phases of being <a href="#ASSIGNED">
! 		ASSIGNED</a> <a href="#RESOLVED"> RESOLVED</a> <a name="#VERIFIED">
! 		VERIFIED</a>. For particularly simple bugs, or for issues considered
! 		to not really be bugs, these phases may be rather brief.

! 		 A bug being marked CLOSED should indicate that we have put
! 		it into some specific release, and placed a suitable reference into
! 		the release notes.

! 		<H2> REOPENED </h2>

! 		<P> Oh, no, the <b>zombie bug!</b>

! 		 Sometimes bugs aren't solved in the first attempt, and need to be
! 		reopened. This is pretty much equivalent to <a href="#ASSIGNED">
! 		ASSIGNED</a>.