Re: Lessons from commit fest - Mailing list pgsql-hackers

Bruce Momjian <bruce@momjian.us> writes:
> There has been talk of the lessons we learned during this commit fest,
> but exactly what lessons did we learn?

Actually, the *main* lesson we learned was "don't start with a
2000-email inbox".  There were a couple of reasons that the queue
was so forbidding:

1. We were in feature freeze for 11 months and consequently built up
a pretty sizable backlog of stuff that had been postponed to 8.4.
We have to avoid ever doing that again.  We've already made some
process changes to try to avoid getting stuck that way, and we have
to be willing to change some more if the current plan doesn't work.
But that wasn't a lesson of the commit fest, we already knew it was
broken :-(.  This was just inevitable pain from our poor management
of the last release cycle.

2. A whole lot of the 2000 emails were not actually about reviewable
patches.  I'm willing to take most of the blame here --- I pushed
Bruce to publish the list before he'd finished doing as much clean-up
as he wanted, and I also encouraged him to leave in some long design
discussion threads that seemed to me to warrant more discussion.
(And part of the reason I thought so was that I'd deliberately ignored
those same threads when they were active, because I was busy trying
to get 8.3 out the door; so again this was partly delayed pain from
the 8.3 mess.)

In hindsight we didn't get very much design discussion done during
the fest, and I think it's unlikely to happen in future either.
We should probably try to limit the focus of fests to consider only
actual patches, with design discussions handled "live" during normal
development, the way they've always been in the past.

A smaller lesson was that you can't start fest without a queue of
ready-to-work-on patches.  We seem to be evolving towards a plan
where stuff gets dumped onto the wiki page more or less immediately
as it comes in.  That should take care of that problem, though I'd
still like to see someone accept responsibility for making sure
patches get listed whether or not their author does it.

Other lessons that were already brought up:
* Bruce's mbox page was not a good status tool, despite his efforts to improve it;
* If Bruce and I are the only ones doing anything, it's gonna be slow.
        regards, tom lane