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
