Tom Lane wrote: > 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.
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 [EMAIL PROTECTED] EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
