Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> 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.
I am just trying to keep everyone happy, the developers, user community,
and patch submitters.
> 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.
Yes, I realize this is a very hard time. I know you were pushing for
end-of-week beta, and though I don't think we can hit that date, I am
trying to move things along. I agree it is that second version of the
patch that often doesn't get the thorough review. Should I increase the
amount of time something is in the queue, or ask for someone to state it
is OK to apply, and just keep asking until I get a "yes" from someone?
I can do that pretty easily.
-- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
