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