On Tuesday 15 May 2007 16:48, Bruce Momjian wrote:
> Joshua D. Drake wrote:
> > > That is not fair to patch submitters, and pushes the problem to 8.4,
> > > where it will be no better.
> >
> > If it isn't done, it isn't done. We aren't dropping the patch. The patch
> > has been accepted, just not reviewed. It is just delayed.
> Delayed isn't rejected, but it isn't accepted either.  I see that as
> unfair to patch submitters, and not making things any easier.  It just
> pushes our problem into 8.4.

So, I'm not sure that these are actual rules, but it's how I have always seen 
the process working:

a) if we cannot resolve a submitted patch of technical issues within a 
reasonable time, it gets pushed to the next release. 

it is at the discression of -core/reviewer to determine both what are 
unresolvable issues and what is an unreasonable time... but I think patches 
that are not making progress within a period of months probably qualify on 
both counts.   

b) the development branch for the next release is not opened until delayed 
patches are dealt with 

dealing with a patch may not mean committing it, if it determined that the 
flaws are enough that it just isnt ready, or the author decides they aren't 
ready to devote time to it. 

i think everyone understands we all want everyones patches to get in, but it 
isn't realistic to think that will happen every release.  

one of the reasons we have a feature freeze is because the community has 
decided that holding up a release for feature X isn't desirable; aiui all of 
the patches in the current queue have been given a once over, and some more 
than that; i'm sure that cycle could go on quite some time for some patches, 
so as unfortunate as it is, I think at some point you have to just suck it up 
and call it day.   all imho.

Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Reply via email to