Re: commit fests

On Fri, Jan 22, 2010 at 5:15 PM, Dimitri Fontaine
<dfontaine(at)hi-media(dot)com> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> I think feature freeze should be the beginning of the last CommitFest,
>> not the end.
>
> So you still want 3 CF per cycle rather than 4?
>  http://archives.postgresql.org/pgsql-hackers/2009-12/msg02355.php
>
> 3 CF and a FixFest… -1 from me, if there's an open vote to be made here.

What I really want is for people to be able to get their patches and
committed in a reasonably timely fashion. 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. Between the start of the last CommitFest for 8.4 and the first
CommitFest for 8.5, 8 months went by. That is a darn long time, and I
think it's hurting the project. It's certainly annoying me, if that
counts for anything.

It appeared to me that Hot Standby, Streaming Replication, and
SE-PostgreSQL basically made no progress (or negative progress, in the
case of the third one) during that time. While I don't want to
venture too far into the realm of speculation, I believe that this may
be partly because (1) there was no chance they'd get committed and (2)
nobody was reviewing them and providing feedback. And I think there
are a lot of other people who just didn't really start to get serious
about finishing their patches until after they got some feedback from
the July CommitFest - a lot of what got marked RWF in July got
committed in September. I think those people were totally right to
blow off trying to get anything done from whenever they wrote the
patch until July, but I also think that it stinks that we ask people
to work that way.

And then there's the actual release schedule. Let's think about what
will happen if 9.0 isn't released until September. First of all,
patches that I wrote in February or March of 2009 will be show up in a
released version 18 months later. That is quite a long time.
Secondly, if the 9.1 cycle turns out to be the same length as the 9.0
cycle, then 9.1 will be released in November or December of 2011,
which means that any patches I write now will wait almost 2 years to
make a released version. That is a REALLY long time, and I'm
skeptical that releasing around the holidays is going to be a success
anyhow. Admittedly, this is all speculative - and just for the
record, if we're able to put out a release in early July as we did for
8.4, I'll be quite happy.

I understand that the majority of the community (or at least a
majority of the vocal community) is not in favor of the relatively
rigid time-based releases for which I am advocating. But I don't
think I am alone in the above-stated frustrations, either. 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 (like, say,
within a year from commit) - because I think those things are
important to the health of the project, and even though FWIH things
are much better than in pre-CommitFest days, I still think there's
quite a bit of room for improvement.

Any ideas?

...Robert