Re: 8.4 release planning - Mailing list pgsql-hackers

> I wish we could get rid of the whole concept and stigma of being "bumped" your
> patch will be released in the next release after it's committed. What does it
> matter if there's been another release since you started or not?

It matters because the intervening beta/release cycle is likely to sap
some focus from the ongoing process of patch review.  If nothing else,
it's a longer period of time before the patch gets another look, and
authors, reviewers, and committers have moved on to other things and
forgotten details that then need to be rehashed.  If we could have
commitfests every two months regardless of the release schedule, then
I think the timing of releases really wouldn't matter as much.  But
then we'd need multiple branches and I don't think Tom et. al. want to
go that route.  And I understand why.  Merging in CVS is the suck, but
even if you can make that aspect of things easier, it's still going to
be some work, and you still have the problem that people might not do
enough testing on release N if they're already in the midst of heavy
development for release N+1.

Linux solves this problem by having back-branch maintainers and
subsystem maintainers who have roles that are intermediate between
random patch submitter and full committer.  We don't really have quite
that much structure, maybe because we're a small project.  But it's
worth thinking about, because if Tom or Peter or Alvaro or Heikki
called me up and said, "If you agree to do be responsible for task X
over the next year, which I estimate will save me 40 hours of work, I
will agree to spend an additional 10 hours over that same time period
reviewing and potentially committing your patches" - I would probably
take that deal. And if I didn't, I bet there are at least five other
people who would be more than happy to get in line.  Of course, making
that work depends on one of those people having a well-defined task
that they trust me (or whoever) to do and that can be severed from the
rest of their work, and there may not be anything of that nature (or
maybe it's at a higher increment, like 200 hours for 50 hours, in
which case it would be more than I could take on, but someone else
might be interested).  But I think that's what we have to look for.  I
don't believe that you can speed a project up much by adjusting the
length of the release cycle, but it is *sometimes* possible to speed
up a project by dividing up the work over more people.

> I would still like an answer to my question about what steps there are that
> take so many months for a release, but I expect most of them boil down to
> (justified) paranoia about testing major features that people haven't already
> tested outside of development environments.

That I'm not sure about.

...Robert