Bruce Momjian wrote:
> Tom Lane wrote:
> > Right at the moment the raw data is still in Bruce's patch queue.
> > It's becoming increasingly obvious that that isn't going to work;
> > we can't have one man being a complete bottleneck for the entire
> > process. I concur with your other suggestion to try to move to
> > a wiki-based patch list, though it's unclear to me just how we
> > should manage that. I think I'd prefer a small number of people
> > (but more than just Bruce) responsible for updating the queue.
>
> Consider I am collecting all our open items from the past 10 months.
> Even when I am done the patch queue is going to be a load of work ---
> take a look at what is there now.
We need storage of patches _outside_ our current patch queue.
As a first problem with the statu quo, it's not possible for other
people to add patches to the queue. Bruce suggests having a special
email address that will allow people to bounce patches to. I see this
as a kludge (a workable one perhaps, but still a kludge). Also it's not
clear how it deals with authorization, though this is probably not a
problem these days.
The second problem is that there's no way to actually extract the patch
from the queue. Cut'n pasting doesn't work, because whitespace is
mangled. So one has to resort (retort?) to extracting the patch from
one own's mbox, which sort of works -- unless it doesn't. And then you
have to work out what's the email containing the latest patch is; if
Bruce added a copy to the queue but the author updated it, how do you
find that out?
As a stopgap measure, a Wiki page could work. Patches should be
attached to the page, or a link to external storage should be posted
(but not to archives, obviously).
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.