Bruce Momjian <bruce@momjian.us> wrote:
> The problem is that the committers control the commit date, but the
> one seen as punished for a rejected patch is not the committers but
> the submitter.
Well, it would seem odd for anyone to feel "punished".
If the patch isn't submitted in good form with the issues hashed out
in prior discussion, and the reviewer(s) and committer(s) can't
resolve the issues prior to the cutoff -- well, try to address those
issues for the next release. Maybe submit with a bit more lead time
next time around.
As is often pointed out here, nothing stops you from using your own
patch if you need to. We did so here, for example, with the standard
character string literals. Had that patch never been accepted, we'd
still be patching new releases. I'm sure that's not always an option,
but I'll bet it often is.
If the submitter is anxious to make a particular release, they should
be motivated to submit early, turn around quickly, and raise a fuss if
the patch seems to be wanting for attention.
One possible solution would be to have trains leaving the station more
often. I know that the idea of more frequent releases has been
proposed and rejected before, but that option is sort of screaming to
be considered again in all of this. Are the mentions of alpha
releases a way to edge into this area -- a feature which misses a
major release could be available to the intrepid within a month or
two, should it then be finished and committed, in a semi-formal way?
-Kevin