From cbbrowne at lists.slony.info  Fri Aug 13 15:13:50 2010
From: cbbrowne at lists.slony.info (Chris Browne)
Date: Fri, 13 Aug 2010 22:13:50 +0000
Subject: [Slony1-commit] slony1-www admin.html index.html index.php
Message-ID: <20100813221350.3F8A929026D@main.slony.info>

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

Modified Files:
	admin.html index.html index.php 
Log Message:
Add in bug management policy document


Index: admin.html
===================================================================
RCS file: /home/cvsd/slony1/slony1-www/admin.html,v
retrieving revision 1.9
retrieving revision 1.10
diff -C 2 -d -r1.9 -r1.10
*** admin.html	15 Jul 2010 21:09:51 -0000	1.9
--- admin.html	13 Aug 2010 22:13:47 -0000	1.10
***************
*** 68,72 ****
                  | <a class="projNav" href=
                  "http://lists.slony.info/mailman/listinfo">Mailing
!                 Lists</a></b></td>
  
                  <td><img src="images/shim.gif" height="1" width=
--- 68,74 ----
                  | <a class="projNav" href=
                  "http://lists.slony.info/mailman/listinfo">Mailing
!                 Lists</a>
! 			    <a class="projNav" href="bug-processing.html">Bug Policy</a>
!                 </b></td>
  
                  <td><img src="images/shim.gif" height="1" width=
***************
*** 271,275 ****
            </address><!-- Created: Thu Jan 25 11:38:58 EST 2007 -->
            <!-- hhmts start -->
! Last modified: Thu Jul 15 16:44:58 EDT 2010
  <!-- hhmts end -->
          </td>
--- 273,277 ----
            </address><!-- Created: Thu Jan 25 11:38:58 EST 2007 -->
            <!-- hhmts start -->
! Last modified: Fri Aug 13 18:09:38 EDT 2010
  <!-- hhmts end -->
          </td>

Index: index.html
===================================================================
RCS file: /home/cvsd/slony1/slony1-www/index.html,v
retrieving revision 1.8
retrieving revision 1.9
diff -C 2 -d -r1.8 -r1.9
*** index.html	15 Jul 2010 21:09:52 -0000	1.8
--- index.html	13 Aug 2010 22:13:47 -0000	1.9
***************
*** 69,74 ****
                  | <a class="projNav" href=
                  "http://lists.slony.info/mailman/listinfo">Mailing
!                 Lists</a></b></td>
! 
                  <td><img src="images/shim.gif" height="1" width=
                  "1"></td>
--- 69,74 ----
                  | <a class="projNav" href=
                  "http://lists.slony.info/mailman/listinfo">Mailing
!                 Lists</a> | <a class="projNav" href=
!                 "bug-processing">Bug Policy</a></b></td>
                  <td><img src="images/shim.gif" height="1" width=
                  "1"></td>
***************
*** 109,155 ****
            here</a>.</p>
  
-           <h1>Slony-I 1.2.7</h1>
- 
-           <p>Now released is version 1.2.7. It has a number of fixes
-           and minor enhancements as listed in the <a href=
-           "http://main.slony.info/viewcvs/viewvc.cgi/slony1-engine/RELEASE-1.2.7?view=log">Release
-           Notes</a> .</p>
- 
-           <p>This has been run thru the <a href=
-           "http://linuxdatabases.info/info/releasechecklist.html">Release
-           Checklist</a></p>
- 
-           <p>There are two tarballs available in the downloads area <a
-           href="http://main.slony.info/downloads/1.2">here</a></p>
- 
-           <h1>Slony-I 1.1.7</h1>
- 
-           <p>Now released is version 1.1.7. It has a number of fixes and minor
-           enhancements as listed in the <a href=
-           "http://main.slony.info/viewcvs/viewvc.cgi/slony1-engine/RELEASE-1.1.7?view=log">Release
-           Notes</a> .</p>
- 
-           <p>This has been run thru the <a href=
-           "http://linuxdatabases.info/info/releasechecklist.html">Release
-           Checklist</a></p>
- 
-           <p>There are two tarballs available in the downloads area <a
-           href="http://main.slony.info/downloads/1.2">here</a></p>
- 
-           <h1>Slony-I and PostgreSQL 8.1</h1>
- 
-           <p>There is a known incompatibility of versions earlier
-           than 1.1.5 with version 8.1; you can expect to see the
-           following error message when compiling:</p>
-           <pre>
- slony1_funcs.c:1081: error: too many arguments to function
- `Async_Unlisten' 
- </pre>
- 
-           <p>A patch for both version 1.1 "STABLE" and CVS HEAD has
-           been committed to CVS; look at both CVS HEAD as well as
-           <tt>REL_1_1_STABLE</tt>. It is in the 1.1.5 release
-           candidate described above.</p>
- 
            <h1>Upgrading Slony-I</h1>
  
--- 109,112 ----
***************
*** 216,220 ****
            </address><!-- Created: Thu Jan 25 11:13:08 EST 2007 -->
            <!-- hhmts start -->
! Last modified: Thu Jul 15 17:00:51 EDT 2010
  <!-- hhmts end -->
          </td>
--- 173,177 ----
            </address><!-- Created: Thu Jan 25 11:13:08 EST 2007 -->
            <!-- hhmts start -->
! Last modified: Fri Aug 13 18:10:34 EDT 2010
  <!-- hhmts end -->
          </td>

Index: index.php
===================================================================
RCS file: /home/cvsd/slony1/slony1-www/index.php,v
retrieving revision 1.13
retrieving revision 1.14
diff -C 2 -d -r1.13 -r1.14
*** index.php	15 Jul 2010 21:09:52 -0000	1.13
--- index.php	13 Aug 2010 22:13:47 -0000	1.14
***************
*** 120,123 ****
--- 120,135 ----
  	echo layout_defaultblock($title,$link,$text);	
  	break;
+   case 'bug-processing':
+ 	echo layout_header();
+ 	$fp = fopen('./content/bug-processing.txt','r');
+ 	if ($fp){
+ 		$title=trim(fgets($fp,256));
+ 		$link=trim(fgets($fp,256));
+ 		$text="";
+ 		while (!feof($fp)) $text.=fgets($fp,256);
+ 		fclose($fp);
+ 	}
+ 	echo layout_defaultblock($title,$link,$text);	
+ 	break;
    default:
  	echo layout_header();


From cbbrowne at lists.slony.info  Fri Aug 13 15:13:50 2010
From: cbbrowne at lists.slony.info (Chris Browne)
Date: Fri, 13 Aug 2010 22:13:50 +0000
Subject: [Slony1-commit] slony1-www/content news.txt
Message-ID: <20100813221350.4C729290429@main.slony.info>

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

Modified Files:
	news.txt 
Log Message:
Add in bug management policy document


Index: news.txt
===================================================================
RCS file: /home/cvsd/slony1/slony1-www/content/news.txt,v
retrieving revision 1.74
retrieving revision 1.75
diff -C 2 -d -r1.74 -r1.75
*** news.txt	15 Jul 2010 21:09:52 -0000	1.74
--- news.txt	13 Aug 2010 22:13:48 -0000	1.75
***************
*** 14,17 ****
--- 14,26 ----
  
  ---
+ Proposed Bug Management Policy
+ http://main.slony.info/bug-management.html.html
+ 2010-08-13
+ Chris Browne
+ 
+ <P> Handling of the Bugzilla instance has been a bit sloppy; there is
+ a proposed document on <a href="bug-management.html"> bug management
+ policy</a>
+ ---
  Git Repository Now Available
  http://main.slony.info/git.html


From cbbrowne at lists.slony.info  Fri Aug 13 15:16:25 2010
From: cbbrowne at lists.slony.info (Chris Browne)
Date: Fri, 13 Aug 2010 22:16:25 +0000
Subject: [Slony1-commit] slony1-www layout.php
Message-ID: <20100813221625.0E271290350@main.slony.info>

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

Modified Files:
	layout.php 
Log Message:
Add bug management stuff to layout


Index: layout.php
===================================================================
RCS file: /home/cvsd/slony1/slony1-www/layout.php,v
retrieving revision 1.15
retrieving revision 1.16
diff -C 2 -d -r1.15 -r1.16
*** layout.php	15 Jul 2010 21:16:53 -0000	1.15
--- layout.php	13 Aug 2010 22:16:22 -0000	1.16
***************
*** 22,25 ****
--- 22,26 ----
      <a href="/downloads/" title="Get Slony!">Download</a>
      <a href="http://bugs.slony.info/bugzilla/" title="Slony-I Bugzilla"> Bugs </a>
+     <a href="/bug-management" title="Bug Policy"> Bug Policy </a>
    </div>
    </div>


From cbbrowne at lists.slony.info  Fri Aug 13 15:17:17 2010
From: cbbrowne at lists.slony.info (Chris Browne)
Date: Fri, 13 Aug 2010 22:17:17 +0000
Subject: [Slony1-commit] slony1-www/content bug-processing.txt
Message-ID: <20100813221717.23423290350@main.slony.info>

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

Added Files:
	bug-processing.txt 
Log Message:
Add bug policy content


--- NEW FILE: bug-processing.txt ---
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>

<p> <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.

<p> The following interpretations are suggested.

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

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

<P> 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
<i>should</i> do the work.

</ul>

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

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

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

<P> 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>

<P> Note that this is <i>not the end</i> of the lifecycle!

<P> 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 <B>RESOLVED/FIXED</B>
<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">

<P> 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>

<P> At this point, for complex patches, we can consider that the patch
has been <B>verified</B> to be valid to be committed and released.

<P> 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">

<P> 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 <i>not really be bugs</i>, these phases may be rather brief.

<P> A bug being marked <B>CLOSED</B> 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>.

From cbbrowne at lists.slony.info  Fri Aug 13 15:23:29 2010
From: cbbrowne at lists.slony.info (Chris Browne)
Date: Fri, 13 Aug 2010 22:23:29 +0000
Subject: [Slony1-commit] slony1-www layout.php
Message-ID: <20100813222329.1DA7F290350@main.slony.info>

Update of /home/cvsd/slony1/slony1-www
In directory main.slony.info:/home/community/slony/htdocs

Modified Files:
	layout.php 
Log Message:
Spell name of bug management file properly


Index: layout.php
===================================================================
RCS file: /home/cvsd/slony1/slony1-www/layout.php,v
retrieving revision 1.16
retrieving revision 1.17
diff -C 2 -d -r1.16 -r1.17
*** layout.php	13 Aug 2010 22:16:22 -0000	1.16
--- layout.php	13 Aug 2010 22:23:27 -0000	1.17
***************
*** 22,26 ****
      <a href="/downloads/" title="Get Slony!">Download</a>
      <a href="http://bugs.slony.info/bugzilla/" title="Slony-I Bugzilla"> Bugs </a>
!     <a href="/bug-management" title="Bug Policy"> Bug Policy </a>
    </div>
    </div>
--- 22,26 ----
      <a href="/downloads/" title="Get Slony!">Download</a>
      <a href="http://bugs.slony.info/bugzilla/" title="Slony-I Bugzilla"> Bugs </a>
!     <a href="/bug-processing" title="Bug Policy"> Bug Policy </a>
    </div>
    </div>


From cbbrowne at lists.slony.info  Fri Aug 13 15:26:56 2010
From: cbbrowne at lists.slony.info (Chris Browne)
Date: Fri, 13 Aug 2010 22:26:56 +0000
Subject: [Slony1-commit] slony1-www layout.php
Message-ID: <20100813222656.F1B20290350@main.slony.info>

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

Modified Files:
	layout.php 
Log Message:
Tab things over - probably needed

Index: layout.php
===================================================================
RCS file: /home/cvsd/slony1/slony1-www/layout.php,v
retrieving revision 1.17
retrieving revision 1.18
diff -C 2 -d -r1.17 -r1.18
*** layout.php	13 Aug 2010 22:23:27 -0000	1.17
--- layout.php	13 Aug 2010 22:26:54 -0000	1.18
***************
*** 22,26 ****
      <a href="/downloads/" title="Get Slony!">Download</a>
      <a href="http://bugs.slony.info/bugzilla/" title="Slony-I Bugzilla"> Bugs </a>
!     <a href="/bug-processing" title="Bug Policy"> Bug Policy </a>
    </div>
    </div>
--- 22,26 ----
      <a href="/downloads/" title="Get Slony!">Download</a>
      <a href="http://bugs.slony.info/bugzilla/" title="Slony-I Bugzilla"> Bugs </a>
!     <a href="/bug-processing" title="Bug Management Policy"> Bug Policy </a>
    </div>
    </div>


From cbbrowne at lists.slony.info  Fri Aug 13 15:26:57 2010
From: cbbrowne at lists.slony.info (Chris Browne)
Date: Fri, 13 Aug 2010 22:26:57 +0000
Subject: [Slony1-commit] slony1-www/content bug-processing.txt
Message-ID: <20100813222657.0DFAD290429@main.slony.info>

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>
  
! <p> <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.
  
! <p> The following interpretations are suggested.
  
! <h2> NEW </h2>
! <a name="NEW">
  
! <P> When a bug is created, it is created with <B>NEW</B> state, is
! assigned to <tt>slony1-bugs at lists.slony.info</tt>, and an email is
! sent to the bug tracking list.
  
! <P> 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
! <i>should</i> do the work.
  
! </ul>
  
! <h2> ASSIGNED </h2>
!   <a name="ASSIGNED">
  
! <P> This is the state of bugs that belong to <i>someone</i>.  That
! someone should presumably be a human, and not
! <tt>slony1-bugs at lists.slony.info</tt>.
  
! <h2> RESOLVED </h2>
!   <a name="RESOLVED">
  
! <P> 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>
  
! <P> Note that this is <i>not the end</i> of the lifecycle!
  
! <P> 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 <B>RESOLVED/FIXED</B>
! <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">
  
! <P> 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>
  
! <P> At this point, for complex patches, we can consider that the patch
! has been <B>verified</B> to be valid to be committed and released.
  
! <P> 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">
  
! <P> 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 <i>not really be bugs</i>, these phases may be rather brief.
  
! <P> A bug being marked <B>CLOSED</B> 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>
  
! 		<p> <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.
  
! 		<p> The following interpretations are suggested.
  
! 		<h2> NEW </h2>
! 		<a name="NEW">
  
! 		<P> When a bug is created, it is created with <B>NEW</B> state, is
! 		assigned to <tt>slony1-bugs at lists.slony.info</tt>, and an email is
! 		sent to the bug tracking list.
  
! 		<P> 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
! 		<i>should</i> do the work.
  
! 		</ul>
  
! 		<h2> ASSIGNED </h2>
! 		  <a name="ASSIGNED">
  
! 		<P> This is the state of bugs that belong to <i>someone</i>.  That
! 		someone should presumably be a human, and not
! 		<tt>slony1-bugs at lists.slony.info</tt>.
  
! 		<h2> RESOLVED </h2>
! 		  <a name="RESOLVED">
  
! 		<P> 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>
  
! 		<P> Note that this is <i>not the end</i> of the lifecycle!
  
! 		<P> 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 <B>RESOLVED/FIXED</B>
! 		<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">
  
! 		<P> 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>
  
! 		<P> At this point, for complex patches, we can consider that the patch
! 		has been <B>verified</B> to be valid to be committed and released.
  
! 		<P> 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">
  
! 		<P> 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 <i>not really be bugs</i>, these phases may be rather brief.
  
! 		<P> A bug being marked <B>CLOSED</B> 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>.


From cbbrowne at lists.slony.info  Fri Aug 13 15:33:29 2010
From: cbbrowne at lists.slony.info (Chris Browne)
Date: Fri, 13 Aug 2010 22:33:29 +0000
Subject: [Slony1-commit] slony1-www layout.php
Message-ID: <20100813223329.E867A29026D@main.slony.info>

Update of /home/cvsd/slony1/slony1-www
In directory main.slony.info:/home/community/slony/htdocs

Modified Files:
	layout.php 
Log Message:
Get rid of text files for Git/bug policy in favor of straight HTML

Index: layout.php
===================================================================
RCS file: /home/cvsd/slony1/slony1-www/layout.php,v
retrieving revision 1.18
retrieving revision 1.19
diff -C 2 -d -r1.18 -r1.19
*** layout.php	13 Aug 2010 22:26:54 -0000	1.18
--- layout.php	13 Aug 2010 22:33:27 -0000	1.19
***************
*** 17,26 ****
    <div class="menu">
      <a href="/" title="Go to the Slony homepage">Home</a>
!     <a href="/git" title="Go to Slony Git information">Git</a>
      <a href="http://lists.slony.info/mailman/listinfo" title="Slony mailinglists">Mailinglists</a>
      <a href="/documentation/" title="Go to the documentation section.">Documentation</a>
      <a href="/downloads/" title="Get Slony!">Download</a>
      <a href="http://bugs.slony.info/bugzilla/" title="Slony-I Bugzilla"> Bugs </a>
!     <a href="/bug-processing" title="Bug Management Policy"> Bug Policy </a>
    </div>
    </div>
--- 17,26 ----
    <div class="menu">
      <a href="/" title="Go to the Slony homepage">Home</a>
!     <a href="/git.html" title="Go to Slony Git information">Git</a>
      <a href="http://lists.slony.info/mailman/listinfo" title="Slony mailinglists">Mailinglists</a>
      <a href="/documentation/" title="Go to the documentation section.">Documentation</a>
      <a href="/downloads/" title="Get Slony!">Download</a>
      <a href="http://bugs.slony.info/bugzilla/" title="Slony-I Bugzilla"> Bugs </a>
!     <a href="/bug-processing.html" title="Bug Management Policy"> Bug Policy </a>
    </div>
    </div>


From cbbrowne at lists.slony.info  Fri Aug 13 15:33:30 2010
From: cbbrowne at lists.slony.info (Chris Browne)
Date: Fri, 13 Aug 2010 22:33:30 +0000
Subject: [Slony1-commit] slony1-www/content bug-processing.txt git.txt
	news.txt
Message-ID: <20100813223330.0D6D2290350@main.slony.info>

Update of /home/cvsd/slony1/slony1-www/content
In directory main.slony.info:/home/community/slony/htdocs/content

Modified Files:
	news.txt 
Removed Files:
	bug-processing.txt git.txt 
Log Message:
Get rid of text files for Git/bug policy in favor of straight HTML

--- bug-processing.txt DELETED ---

--- git.txt DELETED ---

Index: news.txt
===================================================================
RCS file: /home/cvsd/slony1/slony1-www/content/news.txt,v
retrieving revision 1.75
retrieving revision 1.76
diff -C 2 -d -r1.75 -r1.76
*** news.txt	13 Aug 2010 22:13:48 -0000	1.75
--- news.txt	13 Aug 2010 22:33:27 -0000	1.76
***************
*** 15,23 ****
  ---
  Proposed Bug Management Policy
! http://main.slony.info/bug-management.html.html
  2010-08-13
  Chris Browne
  
! <P> Handling of the Bugzilla instance has been a bit sloppy; there is
  a proposed document on <a href="bug-management.html"> bug management
  policy</a>
--- 15,23 ----
  ---
  Proposed Bug Management Policy
! http://main.slony.info/bug-management
  2010-08-13
  Chris Browne
  
! <P> Handling of the Bugzilla instance has been a bit haphazard; there is
  a proposed document on <a href="bug-management.html"> bug management
  policy</a>


From cbbrowne at lists.slony.info  Fri Aug 13 15:34:19 2010
From: cbbrowne at lists.slony.info (Chris Browne)
Date: Fri, 13 Aug 2010 22:34:19 +0000
Subject: [Slony1-commit] slony1-www bug-processing.html
Message-ID: <20100813223419.BD179290CD6@main.slony.info>

Update of /home/cvsd/slony1/slony1-www
In directory main.slony.info:/home/community/slony/htdocs

Added Files:
	bug-processing.html 
Log Message:
Add in bug processing document

--- NEW FILE: bug-processing.html ---
<HTML>
<BODY>
		<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>

		<p> <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.

		<p> The following interpretations are suggested.

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

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

		<P> 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
		<i>should</i> do the work.

		</ul>

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

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

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

		<P> 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>

		<P> Note that this is <i>not the end</i> of the lifecycle!

		<P> 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 <B>RESOLVED/FIXED</B>
		<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">

		<P> 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>

		<P> At this point, for complex patches, we can consider that the patch
		has been <B>verified</B> to be valid to be committed and released.

		<P> 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">

		<P> 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 <i>not really be bugs</i>, these phases may be rather brief.

		<P> A bug being marked <B>CLOSED</B> 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>.


From cbbrowne at lists.slony.info  Fri Aug 13 15:35:19 2010
From: cbbrowne at lists.slony.info (Chris Browne)
Date: Fri, 13 Aug 2010 22:35:19 +0000
Subject: [Slony1-commit] slony1-www bug-processing.html
Message-ID: <20100813223519.8D6E529026D@main.slony.info>

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

Modified Files:
	bug-processing.html 
Log Message:
Make bug policy page prettier

Index: bug-processing.html
===================================================================
RCS file: /home/cvsd/slony1/slony1-www/bug-processing.html,v
retrieving revision 1.1
retrieving revision 1.2
diff -C 2 -d -r1.1 -r1.2
*** bug-processing.html	13 Aug 2010 22:34:17 -0000	1.1
--- bug-processing.html	13 Aug 2010 22:35:17 -0000	1.2
***************
*** 1,4 ****
! <HTML>
! <BODY>
  		<h1>Slony-I Bug Processing</h1>
  			
--- 1,83 ----
! <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
! <html>
!   <head>
!     <title>Slony-I Bug Processing Policy</title>
! <style type="text/css">
! a:link{
!   font-family:lucida,arial,helvetica; font-size: 11px; font-style:normal; font-weight:bold; color:#003399; text-decoration:none;
! }
! a:visited{
!   font-family:lucida,arial,helvetica; font-size: 11px; font-style:normal; font-weight:bold; color:#003399; text-decoration:none;
! }
! a:hover{
!   color:"red"; text-decoration:underline;
! }
! .text TD {
!   font-family:lucida,arial,helvetica; font-size: 11px; font-style:normal;
! }
! .footerText TD {
!   font-family:lucida,arial,helvetica; font-size: 11px; font-style:normal; color:#FFFFFF;
! }
! </style>
!   </head>
! 
!   <body>
!   <table border="0" cellpadding="2" cellspacing="0" width="100%">
!     <tbody>
!       <tr>
!         <td>
!           <table border="0">
!             <tbody>
!               <tr>
!                 <td align="left" valign="top"><img src=
!                 "images/Slon_450x320.jpg" align="left"></td>
! 
!                 <td align="left" valign="top"></td>
!               </tr>
!             </tbody>
!           </table>
! 
!           <table border="0" cellpadding="2" cellspacing="0" width=
!           "100%">
!             <!-- if proj id not empty display proj nav -->
! 
!             <tbody>
!               <tr bgcolor="#000000">
!                 <td colspan="2"><img src="images/shim.gif" height=
!                 "1" width="1"></td>
! 
!                 <td><img src="images/shim.gif" height="1" width=
!                 "1"></td>
!               </tr>
! 
!               <tr bgcolor="#EEEEEE">
!                 <td nowrap="nowrap"><img src="images/shim.gif"
!                 height="1" width="1"><b><a class="adminNav" href=
!                 "admin.html">Project Admin Area</a></b></td>
! 
!                 <td align="right" nowrap="nowrap" width="100%">
!                 <b><a class="projNav" href=
!                 "http://main.slony.info">slony1 Home</a> |
!                 <a class="projNav" href=
!                 "http://slony.info/">Slony-I Website</a> |
!                 <a class="projNav" href="git.html">Git Info</a>
!                 | <a class="projNav" href=
!                 "http://lists.slony.info/mailman/listinfo">Mailing
!                 Lists</a></b></td>
! 
!                 <td><img src="images/shim.gif" height="1" width=
!                 "1"></td>
!               </tr>
! 
!               <tr bgcolor="#000000">
!                 <td colspan="2"><img src="images/shim.gif" height=
!                 "1" width="1"></td>
! 
!                 <td><img src="images/shim.gif" height="1" width=
!                 "1"></td>
!               </tr>
!             </tbody>
!           </table>
! 
  		<h1>Slony-I Bug Processing</h1>
  			


From cbbrowne at lists.slony.info  Wed Aug 18 09:48:25 2010
From: cbbrowne at lists.slony.info (Chris Browne)
Date: Wed, 18 Aug 2010 16:48:25 +0000
Subject: [Slony1-commit] slony1-www bug-processing.html
Message-ID: <20100818164825.49665290CD8@main.slony.info>

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

Modified Files:
	bug-processing.html 
Log Message:
Missed closing </ul> tag


Index: bug-processing.html
===================================================================
RCS file: /home/cvsd/slony1/slony1-www/bug-processing.html,v
retrieving revision 1.2
retrieving revision 1.3
diff -C 2 -d -r1.2 -r1.3
*** bug-processing.html	13 Aug 2010 22:35:17 -0000	1.2
--- bug-processing.html	18 Aug 2010 16:48:22 -0000	1.3
***************
*** 127,130 ****
--- 127,131 ----
  		href="#ASSIGNED">ASSIGNED</A> to someone who might know who
  		<i>should</i> do the work.
+ 		</ul>
  
  		</ul>


From cbbrowne at lists.slony.info  Wed Aug 18 09:50:32 2010
From: cbbrowne at lists.slony.info (Chris Browne)
Date: Wed, 18 Aug 2010 16:50:32 +0000
Subject: [Slony1-commit] slony1-www bug-processing.html
Message-ID: <20100818165032.A5C54290CDB@main.slony.info>

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

Modified Files:
	bug-processing.html 
Log Message:
Missed closing </ul> tag.  (Yes, another one.)


Index: bug-processing.html
===================================================================
RCS file: /home/cvsd/slony1/slony1-www/bug-processing.html,v
retrieving revision 1.3
retrieving revision 1.4
diff -C 2 -d -r1.3 -r1.4
*** bug-processing.html	18 Aug 2010 16:48:22 -0000	1.3
--- bug-processing.html	18 Aug 2010 16:50:30 -0000	1.4
***************
*** 165,168 ****
--- 165,169 ----
  		    <li> A specific Slony developer that is to validate the fix as <a name="#VERIFIED"> VERIFIED</a>
  		  </ul>
+ 		</ul>
  
  		<h2> VERIFIED </h2>


From cbbrowne at lists.slony.info  Wed Aug 18 11:45:43 2010
From: cbbrowne at lists.slony.info (Chris Browne)
Date: Wed, 18 Aug 2010 18:45:43 +0000
Subject: [Slony1-commit] slony1-www bug-processing.html
Message-ID: <20100818184543.EB707290CDB@main.slony.info>

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

Modified Files:
	bug-processing.html 
Log Message:
Add a "work flow perpective"


Index: bug-processing.html
===================================================================
RCS file: /home/cvsd/slony1/slony1-www/bug-processing.html,v
retrieving revision 1.4
retrieving revision 1.5
diff -C 2 -d -r1.4 -r1.5
*** bug-processing.html	18 Aug 2010 16:50:30 -0000	1.4
--- bug-processing.html	18 Aug 2010 18:45:41 -0000	1.5
***************
*** 23,27 ****
  
    <body>
!   <table border="0" cellpadding="2" cellspacing="0" width="100%">
      <tbody>
        <tr>
--- 23,27 ----
  
    <body>
!   <table width="100%" border="0" cellspacing="0" cellpadding="2">
      <tbody>
        <tr>
***************
*** 30,35 ****
              <tbody>
                <tr>
!                 <td align="left" valign="top"><img src=
!                 "images/Slon_450x320.jpg" align="left"></td>
  
                  <td align="left" valign="top"></td>
--- 30,34 ----
              <tbody>
                <tr>
!                 <td align="left" valign="top"><img src="images/Slon_450x320.jpg" alt="" align="left"></td>
  
                  <td align="left" valign="top"></td>
***************
*** 38,79 ****
            </table>
  
!           <table border="0" cellpadding="2" cellspacing="0" width=
!           "100%">
              <!-- if proj id not empty display proj nav -->
  
              <tbody>
                <tr bgcolor="#000000">
!                 <td colspan="2"><img src="images/shim.gif" height=
!                 "1" width="1"></td>
  
!                 <td><img src="images/shim.gif" height="1" width=
!                 "1"></td>
                </tr>
  
                <tr bgcolor="#EEEEEE">
!                 <td nowrap="nowrap"><img src="images/shim.gif"
!                 height="1" width="1"><b><a class="adminNav" href=
!                 "admin.html">Project Admin Area</a></b></td>
  
                  <td align="right" nowrap="nowrap" width="100%">
!                 <b><a class="projNav" href=
!                 "http://main.slony.info">slony1 Home</a> |
!                 <a class="projNav" href=
!                 "http://slony.info/">Slony-I Website</a> |
                  <a class="projNav" href="git.html">Git Info</a>
!                 | <a class="projNav" href=
!                 "http://lists.slony.info/mailman/listinfo">Mailing
                  Lists</a></b></td>
  
!                 <td><img src="images/shim.gif" height="1" width=
!                 "1"></td>
                </tr>
  
                <tr bgcolor="#000000">
!                 <td colspan="2"><img src="images/shim.gif" height=
!                 "1" width="1"></td>
  
!                 <td><img src="images/shim.gif" height="1" width=
!                 "1"></td>
                </tr>
              </tbody>
--- 37,67 ----
            </table>
  
!           <table width="100%" border="0" cellspacing="0" cellpadding="2">
              <!-- if proj id not empty display proj nav -->
  
              <tbody>
                <tr bgcolor="#000000">
!                 <td colspan="2"><img src="images/shim.gif" alt="" height="1" width="1"></td>
  
!                 <td><img src="images/shim.gif" alt="" height="1" width="1"></td>
                </tr>
  
                <tr bgcolor="#EEEEEE">
!                 <td nowrap="nowrap"><img src="images/shim.gif" alt="" height="1" width="1"><b><a class="adminNav" href="admin.html">Project Admin Area</a></b></td>
  
                  <td align="right" nowrap="nowrap" width="100%">
!                 <b><a class="projNav" href="http://main.slony.info">slony1 Home</a> |
!                 <a class="projNav" href="http://slony.info/">Slony-I Website</a> |
                  <a class="projNav" href="git.html">Git Info</a>
!                 | <a class="projNav" href="http://lists.slony.info/mailman/listinfo">Mailing
                  Lists</a></b></td>
  
!                 <td><img src="images/shim.gif" alt="" height="1" width="1"></td>
                </tr>
  
                <tr bgcolor="#000000">
!                 <td colspan="2"><img src="images/shim.gif" alt="" height="1" width="1"></td>
  
!                 <td><img src="images/shim.gif" alt="" height="1" width="1"></td>
                </tr>
              </tbody>
***************
*** 82,130 ****
  		<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>
  
! 		<p> <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.
  
! 		<p> The following interpretations are suggested.
  
  		<h2> NEW </h2>
! 		<a name="NEW">
  
! 		<P> When a bug is created, it is created with <B>NEW</B> state, is
  		assigned to <tt>slony1-bugs at lists.slony.info</tt>, and an email is
! 		sent to the bug tracking list.
  
! 		<P> 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
! 		<i>should</i> do the work.
  		</ul>
  
--- 70,112 ----
  		<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>.</p>
  
  		<h1> Bug Management Process </h1>
  
! 		<p> <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" alt="">
  		to characterize the flow of work on bugs, through various states, as
! 		they (hopefully!) get fixed.</p>
  
! 		<p> The following interpretations are suggested.</p>
  
  		<h2> NEW </h2>
! 		<a name="NEW"></a>
  
! 		<p> When a bug is created, it is created with <b>NEW</b> state, is
  		assigned to <tt>slony1-bugs at lists.slony.info</tt>, and an email is
! 		sent to the bug tracking list.</p>
  
! 		<p> At this point, someone on the Slony development team should
  		examine the bug to ascertain what, if anything, should be done with
! 		it.</p>
  
! 		<p> It may be appropriate to:</p>
  		<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>
  
  		<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>
  
! 		<li> Perhaps the bug is invalid.  Jump straight to <a href="#RESOLVED">RESOLVED</a>.</li>
  
  		<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
! 		<i>should</i> do the work.</li>
  		</ul>
  
***************
*** 132,209 ****
  
  		<h2> ASSIGNED </h2>
! 		  <a name="ASSIGNED">
  
! 		<P> This is the state of bugs that belong to <i>someone</i>.  That
  		someone should presumably be a human, and not
! 		<tt>slony1-bugs at lists.slony.info</tt>.
  
  		<h2> RESOLVED </h2>
! 		  <a name="RESOLVED">
  
! 		<P> 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>
  
! 		<P> Note that this is <i>not the end</i> of the lifecycle!
  
! 		<P> 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 <B>RESOLVED/FIXED</B>
  		<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>
  		</ul>
  
  		<h2> VERIFIED </h2>
! 		  <a name="VERIFIED">
  
! 		<P> 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>
  
! 		<P> At this point, for complex patches, we can consider that the patch
! 		has been <B>verified</B> to be valid to be committed and released.
  
! 		<P> 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">
  
! 		<P> 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 <i>not really be bugs</i>, these phases may be rather brief.
  
! 		<P> A bug being marked <B>CLOSED</B> 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>.
--- 114,244 ----
  
  		<h2> ASSIGNED </h2>
! 		  <a name="ASSIGNED"></a>
  
! 		<p> This is the state of bugs that belong to <i>someone</i>.  That
  		someone should presumably be a human, and not
! 		<tt>slony1-bugs at lists.slony.info</tt>.</p>
  
  		<h2> RESOLVED </h2>
! 		  <a name="RESOLVED"></a>
  
! 		<p> This is the state of bugs that have been addressed, after some
! 		fashion.</p>
  
! 		<p> There are several possible resolutions:</p>
  		<ul>
! 		<li> <b>FIXED</b> - believed to be resolved</li>
! 		<li> <b>DUPLICATE</b> - this apparently duplicates some previous bug</li>
! 		<li> <b>WONTFIX</b> - a problem that we don't plan to address</li>
! 		<li> <b>WORKSFORME</b> - the developer can't duplicate the issue</li>
! 		<li> <b>INVALID</b> - the problem is considered part of the proper behaviour of Slony</li>
  		</ul>
  
! 		<p> Note that this is <i>not the end</i> of the lifecycle!</p>
  
! 		<p> If a developer has a patch for a complex issue, it is appropriate to:</p>
  		<ul>
! 		<li> Attach a patch, or perhaps a reference to a Git commit for the proposed fix.</li>
! 		<li> Mark the bug <b>RESOLVED/FIXED</b></li>
  		<li> Reassign the bug, either to:
  		  <ul>
! 		    <li> The person that reported the bug</li>
! 		    <li> The <tt>slony1-bugs at lists.slony.info</tt> user</li>
! 		    <li> A specific Slony developer that is to validate the fix as <a name="#VERIFIED"> VERIFIED</a></li>
! 		  </ul></li>
  		</ul>
  
  		<h2> VERIFIED </h2>
! 		  <a name="VERIFIED"></a>
  
! 		<p> A developer (or user) takes a <a href="#RESOLVED">RESOLVED</a> bug, and evaluates
! 		whether the resolution provided is proper.</p>
  
! 		<p> The same resolution values apply:</p>
  		<ul>
! 		<li> <b>FIXED</b> - believed to be resolved</li>
! 		<li> <b>DUPLICATE</b> - this apparently duplicates some previous bug</li>
! 		<li> <b>WONTFIX</b> - a problem that we don't plan to address</li>
! 		<li> <b>WORKSFORME</b> - the developer can't duplicate the issue</li>
! 		<li> <b>INVALID</b> - the problem is considered part of the proper behaviour of Slony</li>
  		</ul>
  
! 		<p> At this point, for complex patches, we can consider that the patch
! 		has been <b>verified</b> to be valid to be committed and released.</p>
  
! 		<p> 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...</p>
  
! 		<h2> CLOSED </h2>
! 		  <a name="CLOSED"></a>
  
! 		<p> 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 <i>not really be bugs</i>, these phases may be rather brief.</p>
  
! 		<p> A bug being marked <b>CLOSED</b> should indicate that we have put
  		it into some specific release, and placed a suitable reference into
! 		the release notes.</p>
  
! 		<h2> REOPENED </h2>
  
! 		<p> Oh, no, the <b>zombie bug!</b></p>
  
! 		<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>.</p>
! 
! 		<h1> Alternative Perspective </h1>
! 
! 		<p> Here is how one might expect a typical bug to pass through
! 		the system.</p>
! 
! 		<ul>
! 
! 			  <li> Bug is reported on the mailing list</li>
! 
! 			  <li> Developer copies this over to Bugzilla, creating a
! 			  <a href="#NEW"> NEW</a> bug.</li>
! 
! 			  <li> Developer is reviewing the bug list, and sees a bug
! 				they wish to claim.  They change its status to <a
! 				  href="#ASSIGNED"> ASSIGNED</a>, and assign themself as the
! 				owner.
! 
! 			  <li> Work continues apace.  
! 
! 			  <li> The developer has a proposed patch, which is
! 				assigned to its own Git "topic branch" on their
! 				repository.
! 
! 				<p> The developer attaches a link to this patch, or
! 				perhaps a copy of the patch, to the bug, and marks it
! 				<a href="#RESOLVED"> RESOLVED+FIXED</a>
! 
! 			  <li> Some verification takes place.  Ideally, another
! 				developer confirms that the fix does what it ought to.
! 				Perhaps additional changes go into the patch.
! 
! 			  <li> Consensus is arrived at that the patch is good to
! 				go into one or more branches of Slony-I.
! 				<ul>
! 				  
! 				  <li> The patch is applied to those branches, and
! 				  committed.
! 				  
! 				  <li> Notes about the bug are added to the release
! 				  notes, and committed.  
! 
! 				  <li> They add indication to the bug of application
! 				  of the changes, so readers know what version(s) of
! 				  Slony-I may be expected to have this fix.
! 
! 				  <li> The bug is marked <a href="#CLOSED">
! 					  CLOSED.</a>
! 					
! 				</ul>
! 			</ul>
! 
! </td></tr></tbody></table></body></html>
\ No newline at end of file


From cbbrowne at ca.afilias.info  Tue Aug 24 13:03:58 2010
From: cbbrowne at ca.afilias.info (Christopher Browne)
Date: Tue, 24 Aug 2010 20:03:58 GMT
Subject: [Slony1-commit] Slony-I-commit Ignore C random data generators in
	compiled binary form
Message-ID: <201008242003.o7OK3wUR054495@gothos.postgresql.org>


Commit: http://git.postgresql.org/gitweb?p=slony1-engine.git;a=commitdiff;h=aed76982c99ebf4400f60dc013a0ac7708bf703e

Log Message
-----------
Ignore C random data generators in compiled binary form

Branch
------
REL_2_0_STABLE

Modified Files
--------------
tests/.gitignore |    2 ++
1 files changed, 2 insertions(+), 0 deletions(-)


From JanWieck at Yahoo.com  Tue Aug 24 15:02:09 2010
From: JanWieck at Yahoo.com (Jan Wieck)
Date: Tue, 24 Aug 2010 22:02:09 GMT
Subject: [Slony1-commit] Slony-I-commit Bug 75
Message-ID: <201008242202.o7OM29tl069164@gothos.postgresql.org>


Commit: http://git.postgresql.org/gitweb?p=slony1-engine.git;a=commitdiff;h=3d8606973c4ed5790787cb8b87e662edbb00c3ee

Log Message
-----------
Bug 75

	Call db_commit_xact() at the end of slonik's db_connect() to make
	the session settings for datestyle and replication role permanent.

Branch
------
REL_2_0_STABLE

Modified Files
--------------
src/slonik/dbutil.c |   21 ++++++++++++++++++++-
1 files changed, 20 insertions(+), 1 deletions(-)


From JanWieck at Yahoo.com  Tue Aug 24 15:05:19 2010
From: JanWieck at Yahoo.com (Jan Wieck)
Date: Tue, 24 Aug 2010 22:05:19 GMT
Subject: [Slony1-commit] Slony-I-commit Bug 75
Message-ID: <201008242205.o7OM5JnF069435@gothos.postgresql.org>


Commit: http://git.postgresql.org/gitweb?p=slony1-engine.git;a=commitdiff;h=3dc9fe7f9d021f63fdbb95074dac7eafcb5863c9

Log Message
-----------
Bug 75

	Call db_commit_xact() at the end of slonik's db_connect() to make
	the session settings for datestyle and replication role permanent.
(cherry picked from commit 3d8606973c4ed5790787cb8b87e662edbb00c3ee)

Branch
------
master

Modified Files
--------------
src/slonik/dbutil.c |   21 ++++++++++++++++++++-
1 files changed, 20 insertions(+), 1 deletions(-)


From cbbrowne at ca.afilias.info  Tue Aug 24 15:32:00 2010
From: cbbrowne at ca.afilias.info (Christopher Browne)
Date: Tue, 24 Aug 2010 22:32:00 GMT
Subject: [Slony1-commit] Slony-I-commit Mark version 2.0.5,
	as that's what the present stream of
Message-ID: <201008242232.o7OMW0JQ072015@gothos.postgresql.org>


Commit: http://git.postgresql.org/gitweb?p=slony1-engine.git;a=commitdiff;h=736fe39ec6ef51472c2bb59425c5dbee67479a37

Log Message
-----------
Mark version 2.0.5, as that's what the present stream of changes
will get tagged as.

Branch
------
REL_2_0_STABLE

Modified Files
--------------
config.h.in                  |    4 ++--
src/backend/slony1_funcs.sql |    2 +-
2 files changed, 3 insertions(+), 3 deletions(-)


From JanWieck at Yahoo.com  Wed Aug 25 13:43:41 2010
From: JanWieck at Yahoo.com (Jan Wieck)
Date: Wed, 25 Aug 2010 20:43:41 GMT
Subject: [Slony1-commit] Slony-I-commit Bug #117
Message-ID: <201008252043.o7PKhfOe012503@gothos.postgresql.org>


Commit: http://git.postgresql.org/gitweb?p=slony1-engine.git;a=commitdiff;h=2b77957dc559de43911652c00480b84da4767ea0

Log Message
-----------
Bug #117
Change logging call to omit the write to stdout if we've got and are using only syslog (use_syslog = 2)
(cherry picked from commit 9eb5bce628d7feafb422c6f4b7e65518c8f1bc22)

Branch
------
REL_2_0_STABLE

Modified Files
--------------
src/slon/misc.c |    7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)


From JanWieck at Yahoo.com  Wed Aug 25 13:44:29 2010
From: JanWieck at Yahoo.com (Jan Wieck)
Date: Wed, 25 Aug 2010 20:44:29 GMT
Subject: [Slony1-commit] Slony-I-commit Bug #117
Message-ID: <201008252044.o7PKiTcB012630@gothos.postgresql.org>


Commit: http://git.postgresql.org/gitweb?p=slony1-engine.git;a=commitdiff;h=e6d765bdf724632ae2a95414c2197c51faf4c7e4

Log Message
-----------
Bug #117
Change logging call to omit the write to stdout if we've got and are using only syslog (use_syslog = 2)
(cherry picked from commit 9eb5bce628d7feafb422c6f4b7e65518c8f1bc22)

Branch
------
master

Modified Files
--------------
src/slon/misc.c |    7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)


From cbbrowne at ca.afilias.info  Thu Aug 26 08:30:21 2010
From: cbbrowne at ca.afilias.info (Christopher Browne)
Date: Thu, 26 Aug 2010 15:30:21 GMT
Subject: [Slony1-commit] Slony-I-commit Add release note for bug #117
Message-ID: <201008261530.o7QFULra053187@gothos.postgresql.org>


Commit: http://git.postgresql.org/gitweb?p=slony1-engine.git;a=commitdiff;h=0f9ce08682c38955ac542819704471f1454753e6

Log Message
-----------
Add release note for bug #117

Branch
------
REL_2_0_STABLE

Modified Files
--------------
RELEASE |    2 ++
1 files changed, 2 insertions(+), 0 deletions(-)


From JanWieck at Yahoo.com  Fri Aug 27 09:27:04 2010
From: JanWieck at Yahoo.com (Jan Wieck)
Date: Fri, 27 Aug 2010 16:27:04 GMT
Subject: [Slony1-commit] Slony-I-commit Bug 124
Message-ID: <201008271627.o7RGR4AR039797@gothos.postgresql.org>


Commit: http://git.postgresql.org/gitweb?p=slony1-engine.git;a=commitdiff;h=c6de292bbb3fea189cece38d6bf5bf7c22a9fa92

Log Message
-----------
Bug 124

Enforce that EVENT NODE is identical to EXECUTE ONLY ON node if
the latter is specified.

Also restore the session_replication_role in case ddlScript_prepare
changed it to local.

Branch
------
REL_2_0_STABLE

Modified Files
--------------
doc/adminguide/Makefile        |    1 -
doc/adminguide/slonik_ref.sgml |    5 ++++-
src/backend/slony1_funcs.sql   |   15 +++++++++++++++
src/slonik/slonik.c            |   15 ++++++++++++---
4 files changed, 31 insertions(+), 5 deletions(-)


From JanWieck at Yahoo.com  Fri Aug 27 10:02:22 2010
From: JanWieck at Yahoo.com (Jan Wieck)
Date: Fri, 27 Aug 2010 17:02:22 GMT
Subject: [Slony1-commit] Slony-I-commit Bug 124
Message-ID: <201008271702.o7RH2MHZ043765@gothos.postgresql.org>


Commit: http://git.postgresql.org/gitweb?p=slony1-engine.git;a=commitdiff;h=8708f0aca249e9a004ce6527fdd5f6c22740eae7

Log Message
-----------
Bug 124

Enforce that EVENT NODE is identical to EXECUTE ONLY ON node if
the latter is specified.

Also restore the session_replication_role in case ddlScript_prepare
changed it to local.
(cherry picked from commit c6de292bbb3fea189cece38d6bf5bf7c22a9fa92)

Branch
------
master

Modified Files
--------------
doc/adminguide/slonik_ref.sgml |    5 ++++-
src/backend/slony1_funcs.sql   |   15 +++++++++++++++
src/slonik/slonik.c            |   15 ++++++++++++---
3 files changed, 31 insertions(+), 4 deletions(-)


From cbbrowne at ca.afilias.info  Fri Aug 27 10:22:45 2010
From: cbbrowne at ca.afilias.info (Christopher Browne)
Date: Fri, 27 Aug 2010 17:22:45 GMT
Subject: [Slony1-commit] Slony-I-commit Add release notes for bug #124
Message-ID: <201008271722.o7RHMjtY045655@gothos.postgresql.org>


Commit: http://git.postgresql.org/gitweb?p=slony1-engine.git;a=commitdiff;h=fef86350b4cd9e4640c385ae1aebee1567b0e8bd

Log Message
-----------
Add release notes for bug #124

Branch
------
REL_2_0_STABLE

Modified Files
--------------
RELEASE |    6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)


From ssinger at ca.afilias.info  Fri Aug 27 11:30:13 2010
From: ssinger at ca.afilias.info (Steve Singer)
Date: Fri, 27 Aug 2010 18:30:13 GMT
Subject: [Slony1-commit] Slony-I-commit If a origin node fails a subscriber
	might
Message-ID: <201008271830.o7RIUDBG052210@gothos.postgresql.org>


Commit: http://git.postgresql.org/gitweb?p=slony1-engine.git;a=commitdiff;h=bfa8e601fe7ba1bd91a053901426d4f7195c53a0

Log Message
-----------
If a origin node fails a subscriber might
not be listening for events from the new origin. The FAILOVER event gets
processed on the subscriber but nothing after might be since the
sl_listen rows are setup so all events from the new origin get routed
through the node that used to be the provider(even if a direct
path from the new origin to the subscriber exists).

On processing the FAILOVER event we will mark the old origin as no
inactive.  RebuildListenEntries will now not remove paths that are
dedundent if the (otherwise) preferred path flows through a disabled
node.
(cherry picked from commit 60566590d683b85733404ef290e6c1823c4c014c)

Branch
------
master

Modified Files
--------------
src/backend/slony1_funcs.sql |   11 +++++++++--
1 files changed, 9 insertions(+), 2 deletions(-)


From ssinger at ca.afilias.info  Fri Aug 27 11:30:13 2010
From: ssinger at ca.afilias.info (Steve Singer)
Date: Fri, 27 Aug 2010 18:30:13 GMT
Subject: [Slony1-commit] Slony-I-commit Bug 136
Message-ID: <201008271830.o7RIUDKo052214@gothos.postgresql.org>


Commit: http://git.postgresql.org/gitweb?p=slony1-engine.git;a=commitdiff;h=b30b2d3e52b8c948c601690991ba81f42922dd15

Log Message
-----------
Bug 136
    When a forwarding node goes away a dba might issue a subscribe set to reshape the
    cluster so the receiver gets the data from a different provider.
    It could be the case that the receiver never sees the SUBSCRIBE_SET event
    because it is only listening on events from the origin from the forwarder
    that has gone away.

    If we are reshaping a cluster then slonik will contact the receiver
    directly and run update sl_subscribe so the receiver can
    listen from the correct source.
(cherry picked from commit 0f8305660488d508df6a6ea96bf8ebf57e2e77ea)

Conflicts:

	src/backend/slony1_funcs.sql

Branch
------
master

Modified Files
--------------
src/backend/slony1_funcs.sql |   25 ++++++++++++++++++
src/slonik/slonik.c          |   56 ++++++++++++++++++++++++++++++++++++++++-
2 files changed, 79 insertions(+), 2 deletions(-)


From ssinger at ca.afilias.info  Fri Aug 27 11:30:13 2010
From: ssinger at ca.afilias.info (Steve Singer)
Date: Fri, 27 Aug 2010 18:30:13 GMT
Subject: [Slony1-commit] Slony-I-commit Change query looking for the need to
	"reshape	subscripti
Message-ID: <201008271830.o7RIUDnh052223@gothos.postgresql.org>


Commit: http://git.postgresql.org/gitweb?p=slony1-engine.git;a=commitdiff;h=6797454aec8d75bb99ed7232a44bb121a77b87ad
Author: Christopher Browne <cbbrowne at ca.afilias.info>

Log Message
-----------
Change query looking for the need to "reshape subscription" to
return a count of nodes, rather than the list of nodes.

This is effectively a minor performance tweak.

Branch
------
master

Modified Files
--------------
src/slonik/slonik.c |    9 ++++-----
1 files changed, 4 insertions(+), 5 deletions(-)


From ssinger at ca.afilias.info  Fri Aug 27 11:30:13 2010
From: ssinger at ca.afilias.info (Steve Singer)
Date: Fri, 27 Aug 2010 18:30:13 GMT
Subject: [Slony1-commit] Slony-I-commit Install the signal handlers after
	the fork.
Message-ID: <201008271830.o7RIUDbI052218@gothos.postgresql.org>


Commit: http://git.postgresql.org/gitweb?p=slony1-engine.git;a=commitdiff;h=62e48ee758e0869ec63bc0413f8b6ea167409df2

Log Message
-----------
Install the signal handlers after the fork.
sighandler is intended to be used by the watchdog instance not the worker

This can be considered part of bug 139 (non async safe functions being called
by a signal handler)
(cherry picked from commit 173e7786ddc8ec2ab2b9299fc991573d34e816ba)

Branch
------
master

Modified Files
--------------
src/slon/slon.c |   21 +++++++++++----------
1 files changed, 11 insertions(+), 10 deletions(-)


From ssinger at ca.afilias.info  Fri Aug 27 11:30:13 2010
From: ssinger at ca.afilias.info (Steve Singer)
Date: Fri, 27 Aug 2010 18:30:13 GMT
Subject: [Slony1-commit] Slony-I-commit When doing a fail node where the
	failed node is not a	pr
Message-ID: <201008271830.o7RIUDf9052212@gothos.postgresql.org>


Commit: http://git.postgresql.org/gitweb?p=slony1-engine.git;a=commitdiff;h=f4e33a0a0008796a74a377155fe5b53f16e07c4b

Log Message
-----------
When doing a fail node where the failed node is not a provider of the backup node
we need to delete any subscribe entries that are used to forward data to the backup
node.  These will not be needed when the backup node becomes the new origin.
Until that happens they get in the way of the FAILOVER_SET message
that will be posted on the 'most ahead node' but iwth an origin of
the old origin from getting to this node.
(cherry picked from commit d50fba024aac79020549973e98a4ea9d5bccdab5)

Branch
------
master

Modified Files
--------------
src/backend/slony1_funcs.sql |    4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)


From ssinger at ca.afilias.info  Fri Aug 27 11:30:13 2010
From: ssinger at ca.afilias.info (Steve Singer)
Date: Fri, 27 Aug 2010 18:30:13 GMT
Subject: [Slony1-commit] Slony-I-commit Additional bug 132 fixes:
Message-ID: <201008271830.o7RIUDqH052226@gothos.postgresql.org>


Commit: http://git.postgresql.org/gitweb?p=slony1-engine.git;a=commitdiff;h=8dbeff6b1ba2d27185fb764bd5825a49f3500222

Log Message
-----------
Additional bug 132 fixes:

        The worker will only restart when it can't get the nodelock if
        the worker is in a 'restart' state because it previously
        exited asking its watchdog to restart.

        To faciliate this the watchdog will no longer exec when it needs
        to restart its child but instead just call fork() again.

        Also removing more slon_log instances from the signal handler
        since they are no async safe

Additional fix for bug136:

-Do not use evcommand when calling reshape subscriber since this
function does not generate an event.

Branch
------
master

Modified Files
--------------
src/slon/local_listen.c |   14 ++++-
src/slon/slon.c         |  134 +++++++++++++++++++++++++++++-----------------
src/slonik/slonik.c     |    2 +-
3 files changed, 96 insertions(+), 54 deletions(-)


From ssinger at ca.afilias.info  Fri Aug 27 11:30:13 2010
From: ssinger at ca.afilias.info (Steve Singer)
Date: Fri, 27 Aug 2010 18:30:13 GMT
Subject: [Slony1-commit] Slony-I-commit Only restart the slon during a
	reshape if sl_subscribe	w
Message-ID: <201008271830.o7RIUDWe052224@gothos.postgresql.org>


Commit: http://git.postgresql.org/gitweb?p=slony1-engine.git;a=commitdiff;h=98a425bb206d05734c6d938c341cf188215107ad

Log Message
-----------
Only restart the slon during a reshape if sl_subscribe was
actually updated.

Bug 136 additional fixes
(cherry picked from commit 3c7b70e40bdb913c65e0c5499bc3ac25268da5d4)

Branch
------
master

Modified Files
--------------
src/backend/slony1_funcs.sql |    6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)


From ssinger at ca.afilias.info  Fri Aug 27 11:30:13 2010
From: ssinger at ca.afilias.info (Steve Singer)
Date: Fri, 27 Aug 2010 18:30:13 GMT
Subject: [Slony1-commit] Slony-I-commit Replace usage of alarm() for
	restarting slon with a	KILL
Message-ID: <201008271830.o7RIUDQ9052216@gothos.postgresql.org>


Commit: http://git.postgresql.org/gitweb?p=slony1-engine.git;a=commitdiff;h=2fa20f7e0dd6f9b1ac7830c1f119c4ecf59fd451

Log Message
-----------
Replace usage of alarm() for restarting slon with a KILL of the child
and a sleep before restarting.

Numerous instances were observed where the parent/watchdog slon instance
would exit on a SIGALRM.  The various POSIX standards define rules about
what functions can be called by a signal handler.  We suspect not following
these guidelines was part of the problem.

Branch
------
master

Modified Files
--------------
src/slon/slon.c |   15 ++-------------
1 files changed, 2 insertions(+), 13 deletions(-)


From ssinger at ca.afilias.info  Fri Aug 27 11:30:13 2010
From: ssinger at ca.afilias.info (Steve Singer)
Date: Fri, 27 Aug 2010 18:30:13 GMT
Subject: [Slony1-commit] Slony-I-commit If the nodelock can not be obtained
	then the worker	will
Message-ID: <201008271830.o7RIUD1P052221@gothos.postgresql.org>


Commit: http://git.postgresql.org/gitweb?p=slony1-engine.git;a=commitdiff;h=283bb050e9efb84fcd90151c2432fd1eed4826b1

Log Message
-----------
If the nodelock can not be obtained then the worker will keep retrying instead
of exiting.  Bug # 132 discussses issues where slon can't restart because
of a duplicate node lock.  The watchdog instance of slon can kill the worker
child and restart it.  The issue is that postgresql backend for the old
worker might still be around when the new worker tries to get the nodelock.

Prior to this patch we only had one shot at this, now we will keep retrying
until a user decides to kill this process or the other one goes away
(cherry picked from commit acd46819bad1613764708b138ebcfa895467ac51)

Branch
------
master

Modified Files
--------------
src/slon/local_listen.c |   34 +++++++++++++++++++++-------------
1 files changed, 21 insertions(+), 13 deletions(-)


From ssinger at ca.afilias.info  Fri Aug 27 11:30:28 2010
From: ssinger at ca.afilias.info (Steve Singer)
Date: Fri, 27 Aug 2010 18:30:28 GMT
Subject: [Slony1-commit] Slony-I-commit If a origin node fails a subscriber
	might
Message-ID: <201008271830.o7RIUSCx052302@gothos.postgresql.org>


Commit: http://git.postgresql.org/gitweb?p=slony1-engine.git;a=commitdiff;h=60566590d683b85733404ef290e6c1823c4c014c

Log Message
-----------
If a origin node fails a subscriber might
not be listening for events from the new origin. The FAILOVER event gets
processed on the subscriber but nothing after might be since the
sl_listen rows are setup so all events from the new origin get routed
through the node that used to be the provider(even if a direct
path from the new origin to the subscriber exists).

On processing the FAILOVER event we will mark the old origin as no
inactive.  RebuildListenEntries will now not remove paths that are
dedundent if the (otherwise) preferred path flows through a disabled
node.

Branch
------
REL_2_0_STABLE

Modified Files
--------------
src/backend/slony1_funcs.sql |   11 +++++++++--
1 files changed, 9 insertions(+), 2 deletions(-)


From ssinger at ca.afilias.info  Fri Aug 27 11:30:28 2010
From: ssinger at ca.afilias.info (Steve Singer)
Date: Fri, 27 Aug 2010 18:30:28 GMT
Subject: [Slony1-commit] Slony-I-commit Additional bug 132 fixes:
Message-ID: <201008271830.o7RIUSnc052322@gothos.postgresql.org>


Commit: http://git.postgresql.org/gitweb?p=slony1-engine.git;a=commitdiff;h=7d3e6659542ad337feb2fbe39f05b780c37afe97

Log Message
-----------
Additional bug 132 fixes:

        The worker will only restart when it can't get the nodelock if
        the worker is in a 'restart' state because it previously
        exited asking its watchdog to restart.

        To faciliate this the watchdog will no longer exec when it needs
        to restart its child but instead just call fork() again.

        Also removing more slon_log instances from the signal handler
        since they are no async safe

Additional fix for bug136:

-Do not use evcommand when calling reshape subscriber since this
function does not generate an event.

Branch
------
REL_2_0_STABLE

Modified Files
--------------
src/slon/local_listen.c |   14 ++++-
src/slon/slon.c         |  134 +++++++++++++++++++++++++++++-----------------
src/slonik/slonik.c     |    2 +-
3 files changed, 96 insertions(+), 54 deletions(-)


From ssinger at ca.afilias.info  Fri Aug 27 11:30:28 2010
From: ssinger at ca.afilias.info (Steve Singer)
Date: Fri, 27 Aug 2010 18:30:28 GMT
Subject: [Slony1-commit] Slony-I-commit When doing a fail node where the
	failed node is not a	pr
Message-ID: <201008271830.o7RIUSS4052304@gothos.postgresql.org>


Commit: http://git.postgresql.org/gitweb?p=slony1-engine.git;a=commitdiff;h=d50fba024aac79020549973e98a4ea9d5bccdab5

Log Message
-----------
When doing a fail node where the failed node is not a provider of the backup node
we need to delete any subscribe entries that are used to forward data to the backup
node.  These will not be needed when the backup node becomes the new origin.
Until that happens they get in the way of the FAILOVER_SET message
that will be posted on the 'most ahead node' but iwth an origin of
the old origin from getting to this node.

Branch
------
REL_2_0_STABLE

Modified Files
--------------
src/backend/slony1_funcs.sql |    4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)


From ssinger at ca.afilias.info  Fri Aug 27 11:30:28 2010
From: ssinger at ca.afilias.info (Steve Singer)
Date: Fri, 27 Aug 2010 18:30:28 GMT
Subject: [Slony1-commit] Slony-I-commit If the nodelock can not be obtained
	then the worker	will
Message-ID: <201008271830.o7RIUSe2052313@gothos.postgresql.org>


Commit: http://git.postgresql.org/gitweb?p=slony1-engine.git;a=commitdiff;h=acd46819bad1613764708b138ebcfa895467ac51

Log Message
-----------
If the nodelock can not be obtained then the worker will keep retrying instead
of exiting.  Bug # 132 discussses issues where slon can't restart because
of a duplicate node lock.  The watchdog instance of slon can kill the worker
child and restart it.  The issue is that postgresql backend for the old
worker might still be around when the new worker tries to get the nodelock.

Prior to this patch we only had one shot at this, now we will keep retrying
until a user decides to kill this process or the other one goes away

Branch
------
REL_2_0_STABLE

Modified Files
--------------
src/slon/local_listen.c |   34 +++++++++++++++++++++-------------
1 files changed, 21 insertions(+), 13 deletions(-)


From ssinger at ca.afilias.info  Fri Aug 27 11:30:28 2010
From: ssinger at ca.afilias.info (Steve Singer)
Date: Fri, 27 Aug 2010 18:30:28 GMT
Subject: [Slony1-commit] Slony-I-commit Bug 136
Message-ID: <201008271830.o7RIUSx1052307@gothos.postgresql.org>


Commit: http://git.postgresql.org/gitweb?p=slony1-engine.git;a=commitdiff;h=0f8305660488d508df6a6ea96bf8ebf57e2e77ea

Log Message
-----------
Bug 136
    When a forwarding node goes away a dba might issue a subscribe set to reshape the
    cluster so the receiver gets the data from a different provider.
    It could be the case that the receiver never sees the SUBSCRIBE_SET event
    because it is only listening on events from the origin from the forwarder
    that has gone away.

    If we are reshaping a cluster then slonik will contact the receiver
    directly and run update sl_subscribe so the receiver can
    listen from the correct source.

Branch
------
REL_2_0_STABLE

Modified Files
--------------
src/backend/slony1_funcs.sql |   24 ++++++++++++++++++
src/slonik/slonik.c          |   56 ++++++++++++++++++++++++++++++++++++++++-
2 files changed, 78 insertions(+), 2 deletions(-)


From ssinger at ca.afilias.info  Fri Aug 27 11:30:28 2010
From: ssinger at ca.afilias.info (Steve Singer)
Date: Fri, 27 Aug 2010 18:30:28 GMT
Subject: [Slony1-commit] Slony-I-commit Install the signal handlers after
	the fork.
Message-ID: <201008271830.o7RIUSpH052310@gothos.postgresql.org>


Commit: http://git.postgresql.org/gitweb?p=slony1-engine.git;a=commitdiff;h=173e7786ddc8ec2ab2b9299fc991573d34e816ba

Log Message
-----------
Install the signal handlers after the fork.
sighandler is intended to be used by the watchdog instance not the worker

This can be considered part of bug 139 (non async safe functions being called
by a signal handler)

Branch
------
REL_2_0_STABLE

Modified Files
--------------
src/slon/slon.c |   21 +++++++++++----------
1 files changed, 11 insertions(+), 10 deletions(-)


From ssinger at ca.afilias.info  Fri Aug 27 11:30:28 2010
From: ssinger at ca.afilias.info (Steve Singer)
Date: Fri, 27 Aug 2010 18:30:28 GMT
Subject: [Slony1-commit] Slony-I-commit Replace usage of alarm() for
	restarting slon with a	KILL
Message-ID: <201008271830.o7RIUSdt052308@gothos.postgresql.org>


Commit: http://git.postgresql.org/gitweb?p=slony1-engine.git;a=commitdiff;h=e692b6c6ecee3a6ff0539a40245dbceb4ef8f85c

Log Message
-----------
Replace usage of alarm() for restarting slon with a KILL of the child
and a sleep before restarting.

Numerous instances were observed where the parent/watchdog slon instance
would exit on a SIGALRM.  The various POSIX standards define rules about
what functions can be called by a signal handler.  We suspect not following
these guidelines was part of the problem.

Branch
------
REL_2_0_STABLE

Modified Files
--------------
src/slon/slon.c |   15 ++-------------
1 files changed, 2 insertions(+), 13 deletions(-)


From ssinger at ca.afilias.info  Fri Aug 27 11:30:28 2010
From: ssinger at ca.afilias.info (Steve Singer)
Date: Fri, 27 Aug 2010 18:30:28 GMT
Subject: [Slony1-commit] Slony-I-commit Change query looking for the need to
	"reshape	subscripti
Message-ID: <201008271830.o7RIUSgD052316@gothos.postgresql.org>


Commit: http://git.postgresql.org/gitweb?p=slony1-engine.git;a=commitdiff;h=301e9300345314f3d84cdfee83d112cd6922e673
Author: Christopher Browne <cbbrowne at ca.afilias.info>

Log Message
-----------
Change query looking for the need to "reshape subscription" to
return a count of nodes, rather than the list of nodes.

This is effectively a minor performance tweak.

Branch
------
REL_2_0_STABLE

Modified Files
--------------
src/slonik/slonik.c |    9 ++++-----
1 files changed, 4 insertions(+), 5 deletions(-)


From ssinger at ca.afilias.info  Fri Aug 27 11:30:28 2010
From: ssinger at ca.afilias.info (Steve Singer)
Date: Fri, 27 Aug 2010 18:30:28 GMT
Subject: [Slony1-commit] Slony-I-commit Updating release notes for Bugs 132,
	139 and 136.
Message-ID: <201008271830.o7RIUSOC052324@gothos.postgresql.org>


Commit: http://git.postgresql.org/gitweb?p=slony1-engine.git;a=commitdiff;h=2101ab5da03e555d3822280f4f8e385306021f28

Log Message
-----------
Updating release notes for Bugs 132, 139 and 136.

Branch
------
REL_2_0_STABLE

Modified Files
--------------
RELEASE |    8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)


From ssinger at ca.afilias.info  Fri Aug 27 11:30:28 2010
From: ssinger at ca.afilias.info (Steve Singer)
Date: Fri, 27 Aug 2010 18:30:28 GMT
Subject: [Slony1-commit] Slony-I-commit Only restart the slon during a
	reshape if sl_subscribe	w
Message-ID: <201008271830.o7RIUSxM052317@gothos.postgresql.org>


Commit: http://git.postgresql.org/gitweb?p=slony1-engine.git;a=commitdiff;h=3c7b70e40bdb913c65e0c5499bc3ac25268da5d4

Log Message
-----------
Only restart the slon during a reshape if sl_subscribe was
actually updated.

Bug 136 additional fixes

Branch
------
REL_2_0_STABLE

Modified Files
--------------
src/backend/slony1_funcs.sql |    6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)


From JanWieck at Yahoo.com  Fri Aug 27 11:49:40 2010
From: JanWieck at Yahoo.com (Jan Wieck)
Date: Fri, 27 Aug 2010 18:49:40 GMT
Subject: [Slony1-commit] Slony-I-commit Bug 149
Message-ID: <201008271849.o7RIneIG054176@gothos.postgresql.org>


Commit: http://git.postgresql.org/gitweb?p=slony1-engine.git;a=commitdiff;h=fe2b8e9dca5a9219250e13832b47e91f366f9c13

Log Message
-----------
Bug 149

Fix for when local listen fails to start properly. It was observed that slon can wait for the local listen cond to be set where the local listener thread stops on an error. In this case we want to signal the mutex but flag the local listener as not having started. The main slon thread should then abort.
(cherry picked from commit ba234cfe686f33fd10d2af1c557af66f8ec17b02)

Branch
------
REL_2_0_STABLE

Modified Files
--------------
src/slon/local_listen.c |   11 +++++++++++
src/slon/slon.c         |    9 +++++++++
src/slon/slon.h         |    2 +-
3 files changed, 21 insertions(+), 1 deletions(-)


From JanWieck at Yahoo.com  Fri Aug 27 11:51:25 2010
From: JanWieck at Yahoo.com (Jan Wieck)
Date: Fri, 27 Aug 2010 18:51:25 GMT
Subject: [Slony1-commit] Slony-I-commit Fix for when local listen fails to
	start properly. It	wa
Message-ID: <201008271851.o7RIpPfI054412@gothos.postgresql.org>


Commit: http://git.postgresql.org/gitweb?p=slony1-engine.git;a=commitdiff;h=636bc48fdeddf11bf27d93640febb53cc656fa1e
Author: Steve Singer <ssinger at ca.afilias.info>

Log Message
-----------
Fix for when local listen fails to start properly. It was observed that slon can wait for the local listen cond to be set where the local listener thread stops on an error. In this case we want to signal the mutex but flag the local listener as not having started. The main slon thread should then abort.
(cherry picked from commit ba234cfe686f33fd10d2af1c557af66f8ec17b02)

Branch
------
master

Modified Files
--------------
src/slon/local_listen.c |   11 +++++++++++
src/slon/slon.c         |    9 +++++++++
src/slon/slon.h         |    2 +-
3 files changed, 21 insertions(+), 1 deletions(-)


From JanWieck at Yahoo.com  Fri Aug 27 12:06:25 2010
From: JanWieck at Yahoo.com (Jan Wieck)
Date: Fri, 27 Aug 2010 19:06:25 GMT
Subject: [Slony1-commit] Slony-I-commit Bug #115
Message-ID: <201008271906.o7RJ6PtH055818@gothos.postgresql.org>


Commit: http://git.postgresql.org/gitweb?p=slony1-engine.git;a=commitdiff;h=783eee0a78628e62ae081fbebd366f9d3fad5af8

Log Message
-----------
Bug #115

Cause the parser to generate an ERROR if a WAIT FOR EVENT
occurs inside of a TRY block.

In reality, the wait itself isn't the problem. It is the combination
of creating the event (sync, store whatever) and waiting for it
inside the same try block. Try blocks don't commit until they end,
so the event never gets committed and logically, the wait must wait
forever.

Branch
------
REL_2_0_STABLE

Modified Files
--------------
src/slonik/parser.y |   36 ++++++++++++++++++++++++++++++++----
1 files changed, 32 insertions(+), 4 deletions(-)


From JanWieck at Yahoo.com  Fri Aug 27 12:07:53 2010
From: JanWieck at Yahoo.com (Jan Wieck)
Date: Fri, 27 Aug 2010 19:07:53 GMT
Subject: [Slony1-commit] Slony-I-commit Bug #115
Message-ID: <201008271907.o7RJ7roD055983@gothos.postgresql.org>


Commit: http://git.postgresql.org/gitweb?p=slony1-engine.git;a=commitdiff;h=939d9781c9aedf3e5366ed4ec1f3e8cce746b278

Log Message
-----------
Bug #115

Cause the parser to generate an ERROR if a WAIT FOR EVENT
occurs inside of a TRY block.

In reality, the wait itself isn't the problem. It is the combination
of creating the event (sync, store whatever) and waiting for it
inside the same try block. Try blocks don't commit until they end,
so the event never gets committed and logically, the wait must wait
forever.
(cherry picked from commit 783eee0a78628e62ae081fbebd366f9d3fad5af8)

Branch
------
master

Modified Files
--------------
src/slonik/parser.y |   36 ++++++++++++++++++++++++++++++++----
1 files changed, 32 insertions(+), 4 deletions(-)


From ssinger at ca.afilias.info  Fri Aug 27 13:28:09 2010
From: ssinger at ca.afilias.info (Steve Singer)
Date: Fri, 27 Aug 2010 20:28:09 GMT
Subject: [Slony1-commit] Slony-I-commit Revert "Bug 149"
Message-ID: <201008272028.o7RKS9lL063927@gothos.postgresql.org>


Commit: http://git.postgresql.org/gitweb?p=slony1-engine.git;a=commitdiff;h=3d1ee45dfb40da8b40f6b72a9336ac0a1617ef88

Log Message
-----------
Revert "Bug 149"

This reverts commit fe2b8e9dca5a9219250e13832b47e91f366f9c13.

The commit was the result of a mis-merged rebase. The fix will
get re-applied once the patch is properly merged.

Branch
------
REL_2_0_STABLE

Modified Files
--------------
src/slon/local_listen.c |   11 -----------
src/slon/slon.c         |    9 ---------
src/slon/slon.h         |    2 +-
3 files changed, 1 insertions(+), 21 deletions(-)


From cbbrowne at ca.afilias.info  Fri Aug 27 14:28:23 2010
From: cbbrowne at ca.afilias.info (Christopher Browne)
Date: Fri, 27 Aug 2010 21:28:23 GMT
Subject: [Slony1-commit] Slony-I-commit Add release notes for bug #149
Message-ID: <201008272128.o7RLSNpg069557@gothos.postgresql.org>


Commit: http://git.postgresql.org/gitweb?p=slony1-engine.git;a=commitdiff;h=8f08f92de1f21b6f30af4b8f1e87976745cbbe74

Log Message
-----------
Add release notes for bug #149

Branch
------
REL_2_0_STABLE

Modified Files
--------------
RELEASE |    1 +
1 files changed, 1 insertions(+), 0 deletions(-)


From cbbrowne at ca.afilias.info  Fri Aug 27 14:28:23 2010
From: cbbrowne at ca.afilias.info (Christopher Browne)
Date: Fri, 27 Aug 2010 21:28:23 GMT
Subject: [Slony1-commit] Slony-I-commit Release notes for bug #115
Message-ID: <201008272128.o7RLSNoa069559@gothos.postgresql.org>


Commit: http://git.postgresql.org/gitweb?p=slony1-engine.git;a=commitdiff;h=ebc9ac0054cf6ef0df09c08fd19c3e0613fffee4

Log Message
-----------
Release notes for bug #115

Branch
------
REL_2_0_STABLE

Modified Files
--------------
RELEASE |   18 +++++++++++-------
1 files changed, 11 insertions(+), 7 deletions(-)


From cbbrowne at ca.afilias.info  Fri Aug 27 15:26:51 2010
From: cbbrowne at ca.afilias.info (Christopher Browne)
Date: Fri, 27 Aug 2010 22:26:51 GMT
Subject: [Slony1-commit] Slony-I-commit Add more files ignorable by git
	because they are	generat
Message-ID: <201008272226.o7RMQpO7074943@gothos.postgresql.org>


Commit: http://git.postgresql.org/gitweb?p=slony1-engine.git;a=commitdiff;h=fe2bd11949c6a0477f174f44d39340b482bc30b9

Log Message
-----------
Add more files ignorable by git because they are generated as parts of builds

Branch
------
master

Modified Files
--------------
doc/concept/.gitignore |    6 ++----
tests/.gitignore       |    2 ++
2 files changed, 4 insertions(+), 4 deletions(-)


From cbbrowne at ca.afilias.info  Mon Aug 30 12:23:11 2010
From: cbbrowne at ca.afilias.info (Christopher Browne)
Date: Mon, 30 Aug 2010 19:23:11 GMT
Subject: [Slony1-commit] Slony-I-commit Change "enable-thread-safety"
	checking to only exclude	L
Message-ID: <201008301923.o7UJNB7q084143@gothos.postgresql.org>


Commit: http://git.postgresql.org/gitweb?p=slony1-engine.git;a=commitdiff;h=63fc4a2103676132490384cf128af458a9d226de

Log Message
-----------
Change "enable-thread-safety" checking to only exclude Linux from this
testing, rather than merely testing on AIX/Solaris, per bug #40

Branch
------
REL_2_0_STABLE

Modified Files
--------------
config/acx_libpq.m4 |   10 +++++++---
1 files changed, 7 insertions(+), 3 deletions(-)


From cbbrowne at ca.afilias.info  Mon Aug 30 12:23:11 2010
From: cbbrowne at ca.afilias.info (Christopher Browne)
Date: Mon, 30 Aug 2010 19:23:11 GMT
Subject: [Slony1-commit] Slony-I-commit Merge branch 'bug40' into
	REL_2_0_STABLE
Message-ID: <201008301923.o7UJNBxC084146@gothos.postgresql.org>


Commit: http://git.postgresql.org/gitweb?p=slony1-engine.git;a=commitdiff;h=b67d646f1d83088ceb3348be520b5a35e26b7100

Log Message
-----------
Merge branch 'bug40' into REL_2_0_STABLE

Branch
------
REL_2_0_STABLE

Modified Files
--------------


From cbbrowne at ca.afilias.info  Mon Aug 30 12:23:11 2010
From: cbbrowne at ca.afilias.info (Christopher Browne)
Date: Mon, 30 Aug 2010 19:23:11 GMT
Subject: [Slony1-commit] Slony-I-commit Release notes for bug #40
Message-ID: <201008301923.o7UJNBI8084147@gothos.postgresql.org>


Commit: http://git.postgresql.org/gitweb?p=slony1-engine.git;a=commitdiff;h=80f40a2446c93fe3e2637616961b0e1e56f25043

Log Message
-----------
Release notes for bug #40

Branch
------
REL_2_0_STABLE

Modified Files
--------------
RELEASE |    2 ++
1 files changed, 2 insertions(+), 0 deletions(-)


From cbbrowne at ca.afilias.info  Mon Aug 30 12:23:11 2010
From: cbbrowne at ca.afilias.info (Christopher Browne)
Date: Mon, 30 Aug 2010 19:23:11 GMT
Subject: [Slony1-commit] Slony-I-commit generated SGML should be ignored by
	git
Message-ID: <201008301923.o7UJNBX1084141@gothos.postgresql.org>


Commit: http://git.postgresql.org/gitweb?p=slony1-engine.git;a=commitdiff;h=a17ce6951f33fc4bc38131d1eefe3fc3193944a1

Log Message
-----------
generated SGML should be ignored by git

Conflicts:

	doc/adminguide/.gitignore

Branch
------
REL_2_0_STABLE

Modified Files
--------------
doc/adminguide/.gitignore |   77 ++++++++++++++++++++++++---------------------
1 files changed, 41 insertions(+), 36 deletions(-)


From cbbrowne at ca.afilias.info  Mon Aug 30 12:23:11 2010
From: cbbrowne at ca.afilias.info (Christopher Browne)
Date: Mon, 30 Aug 2010 19:23:11 GMT
Subject: [Slony1-commit] Slony-I-commit factor apart OS tests
Message-ID: <201008301923.o7UJNBaY084139@gothos.postgresql.org>


Commit: http://git.postgresql.org/gitweb?p=slony1-engine.git;a=commitdiff;h=8b45b75a6482f4aea31d44313e34c43dd6497d8e

Log Message
-----------
factor apart OS tests
thread safety isn't related to win32 stuff, so the logic seems simpler if we separate them

Branch
------
REL_2_0_STABLE

Modified Files
--------------
config/acx_libpq.m4 |   14 +++++++++-----
1 files changed, 9 insertions(+), 5 deletions(-)


From cbbrowne at ca.afilias.info  Mon Aug 30 12:28:49 2010
From: cbbrowne at ca.afilias.info (Christopher Browne)
Date: Mon, 30 Aug 2010 19:28:49 GMT
Subject: [Slony1-commit] Slony-I-commit Bug #40 - use PGisthreadsafe() to
	test thread safety	in
Message-ID: <201008301928.o7UJSnNW084627@gothos.postgresql.org>


Commit: http://git.postgresql.org/gitweb?p=slony1-engine.git;a=commitdiff;h=d747d9c97beeace62a1798e9b81807ca5727de3c

Log Message
-----------
Bug #40 - use PGisthreadsafe() to test thread safety in configure

Branch
------
REL_2_0_STABLE

Modified Files
--------------
config/acx_libpq.m4 |   30 +++++++++++-------------------
1 files changed, 11 insertions(+), 19 deletions(-)


From cbbrowne at ca.afilias.info  Mon Aug 30 12:30:32 2010
From: cbbrowne at ca.afilias.info (Christopher Browne)
Date: Mon, 30 Aug 2010 19:30:32 GMT
Subject: [Slony1-commit] Slony-I-commit Bug #40 - apply to HEAD
Message-ID: <201008301930.o7UJUWFP085029@gothos.postgresql.org>


Commit: http://git.postgresql.org/gitweb?p=slony1-engine.git;a=commitdiff;h=ce8854ccb0c21ff50cc957000f0775d2afdc051d

Log Message
-----------
Bug #40 - apply to HEAD

Branch
------
master

Modified Files
--------------
config/acx_libpq.m4 |   26 +++++++++++++-------------
1 files changed, 13 insertions(+), 13 deletions(-)