Bruce Momjian <[EMAIL PROTECTED]> writes:
> Alvaro Herrera wrote:
>> This rush to apply patches just because no one seems to be capable of
>> keeping up with them not being reviewed, is starting to get a bit
>> worrisome.
> When things are placed in the patches queue, I need to get feedback if
> there is a problem with them. I am not sure what other process we can
> follow, unless we just keep patches there indefinitely, or just ignore
> them and never place them in the queue.
The problem with the process you're using is that it defaults to
applying patches --- and in fact, lately it seems like it takes a
threat of mayhem to prevent you from applying a patch.
Now, apply-unless-objected-to was the right default back in 1997, when
the code was in bad enough shape that it was hard to make it worse ;-).
I do not believe it's the right default anymore though. The system is a
lot larger and more complicated than it was when it left Berkeley, and
our quality standards are an order of magnitude higher too. We need to
default to *not* applying patches until they've passed some amount of
review.
I don't want to be too hard-nosed about this, since the last thing we
need is another level of bureaucracy added to our processes, especially
for simple trivial stuff. But when there's been some discussion or
objection to a patch, ISTM that just because the patch submitter has
put up a second version should not mean that it's okay to apply. At
that point some actual review is needed.
I'm also having a bit of a problem with the silence-means-assent rule.
Most of the time I'm OK with it, but right now I simply don't have the
time to look at everything that comes in as soon as it comes in;
especially not second versions of patches.
I don't have a concrete proposal to make, but I do think that the
current patch-queue process is not suited to the project as it stands
today. Maybe if this issue-tracking stuff gets off the ground, we
could let developers place ACK or NAK flags on patches they've looked
at, and have some rule about ACK-vs-NAK requirements for something to go
in.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
