Re: Patch queue -> wiki - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Patch queue -> wiki
Date
Msg-id 27542.1207363037@sss.pgh.pa.us
Whole thread Raw
In response to Re: Patch queue -> wiki  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Patch queue -> wiki  (Bruce Momjian <bruce@momjian.us>)
Re: Patch queue -> wiki  ("Joshua D. Drake" <jd@commandprompt.com>)
List pgsql-hackers
Bruce Momjian <bruce@momjian.us> writes:
> I think ultimately we are going to have to remove the patches email list
> and require patch submitters to add their patches to a patch tracker. 

That's outright silly.  The email list and archives are a critical part
of what we do, because they provide a historical record.  Nor is raising
the bar for submitting patches a good idea.

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.

> Frankly, few people seem to want to apply patches either.  :-)

Yeah, tell me about it :-(
        regards, tom lane


pgsql-hackers by date:

Previous
From: Gregory Stark
Date:
Subject: Re: Patch queue -> wiki
Next
From: Bruce Momjian
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Implement current_query(), that shows the currently executing