From: Bruce Momjian <bruce@momjian.us>
Message-Id: <200804050243.m352hgm05989@momjian.us>
Subject: Re: Patch queue -> wiki
In-Reply-To: <27542.1207363037@sss.pgh.pa.us>
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Fri, 4 Apr 2008 22:43:42 -0400 (EDT)
CC: Alvaro Herrera <alvherre@commandprompt.com>,
	Gregory Stark <stark@enterprisedb.com>, Greg Smith <gsmith@gregsmith.com>,
	Pg Hackers <pgsql-hackers@postgresql.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"

Tom Lane wrote:
> The patch queue is by definition transient --- nobody particularly cares
> about what its past state was, as shown by the fact that you've gotten
> along for years with an implementation that's incapable of recalling
> past state.  (Now I do like the idea that a wiki-based patch queue would
> retain some history, but I'm not expecting that it'll archive every
> change indefinitely.)
> 
> The right way to think about and design the patch queue is as a changing
> index into the archives.  One of the things I seriously dislike about
> your current implementation is that it ignores the archives.  You've
> whacked us around two or three times this month developing "permanent"
> and then "really permanent" URLs, but that whole thing is wrong from the
> get-go.  You are not the keeper of the project's historical record.
> The patch queue should be trafficking in URLs that do point into the
> historical record.

Sure, it would be nice if an email link could jump right into the
archives, but until we have a way to get to the archives via a
message-id, I know of know way to automate that.

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +