Re: commit fests

Robert Haas <robertmhaas@gmail.com> wrote:
> That means I'd like releases to be reasonably frequent - like
> annually - and I'd like the time for which nobody can get anything
> committed to be relatively short.
Yeah, the current approach seems to be to develop a schedule around
a one-year cycle, with an implicit assumption that the date will
never actually be hit, so the release cycle will really be 15 months
or more.  Just don't say it out loud [oops].  Close to half of that
is effectively closed to submissions from non-committers.
> if we're able to put out a release in early July as we did for
> 8.4, I'll be quite happy.
Well, six months from the start of the last CF to release seems like
it would leave a lot of room for improvement in project management
techniques, but at this point July would be a happy thing just
because I currently get the sense that we're actually on track for a
release well past that.
> What I'd really like is to stop arguing about the number of
> CommitFests per cycle and the exact charter of each CommitFest and
> start talking about how we can create an environment where patch
> authors can get their work committed reasonably quickly (assuming
> it's good, of course) and released within some reasonable time
> frame after that
Dimitri's reply with the "Too bad we can't have" portion makes me
wonder whether we really can't.  Does it really take the concerted
efforts of the whole community five months to take things from the
deadline for patch commits (end of last CF) to release?  Is it that
nobody would volunteer to take the burden of that effort so that
others could code?  Perhaps it isn't that five months is outrageous,
but that it doesn't really benefit from an unorganized swarm of
activity by all the developers, and we've not worked out a
reasonable framework for who should do what during that time to best
benefit the project while giving all these volunteer and sponsored
developers something they are willing to put effort into.
At the risk of hanging a big "slacker" bulls-eye on my chest, I will
say that while I've managed to get approval from management here to
test prior releases during their beta periods "on the clock", with
the justification that it would catch bugs which affect our "unique"
environment before have to try to bring it in for production use,
that is simply not an option this time.  Any such contribution would
have to be off-hours (like today), because they have become
convinced of the need for a particular PostgreSQL feature that
nobody else is addressing and authorized time for that; and there's
no way they're going to pay for both this year.  I don't know how
many other find themselves in such binds, but I'm sure it happens.
-Kevin