Re: commit fests

From: Greg Smith <greg(at)2ndquadrant(dot)com>
To: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: commit fests
Date: 2010-01-23 19:25:21
Message-ID: 4B5B4D21.5060109@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Kevin Grittner wrote:
> 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?

The idea is that it takes five months of complete lockdown to give the
code enough testing time to hopefully reach stability. I don't think
that part is particularly controversial--reduce it, and quality drops,
period. And as pointed out by a couple of people, even one release per
year of a database is more than many users really want to consume, as
evidenced by the number of 7.X installs still going because "we don't
want to touch the working app" we still hear about.

The question then is what else you could be doing during that period.
Let's say that the day 9.0 beta 1 came out, a new 9.1 branch was created
and CommitFests against it started, during what right now would be time
exclusively devoted to beta testing. Completely feasible idea. There
would be some forward/backporting duplication of work while those were
running in parallel, and that would be harder than it needs to be until
something like a git transition happens. But you certainly could do it.

So why not do that? Developing new features is fun and tends to attract
sponsorship dollars. Testing a frozen release, finding bugs, and
resolving them is boring, and no one sponsors it. Therefore, if you let
both things go on at once, I guarantee you almost all of the community
attention will be diverted toward new development during any period
where both are happening at the same time. Give developers a choice
between shiny and profitable vs. dull and unpaid, and they'll focus on
the former every time. That means that there's no possible way you can
keep new development open without hurting the dreary work around
stabilizing the beta in the process. You have to put all the fun toys
away in order to keep focus on the painful parts.

Plenty of other projects don't work this way, with a beta drop being a
kick off to resume full-on development. There's a reason why PostgreSQL
has a better reputation for quality releases than they do. It's an
enterprise-class database; you don't just throw code in there, release
the result every quarter, and expect the result to be stable. If
developers are turned away because they want more instant gratification
for their development efforts, they're working on the wrong type of
project for them.

--
Greg Smith 2ndQuadrant Baltimore, MD
PostgreSQL Training, Services and Support
greg(at)2ndQuadrant(dot)com www.2ndQuadrant.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David E. Wheeler 2010-01-23 19:42:59 Re: Miscellaneous changes to plperl [PATCH]
Previous Message Alex Hunsaker 2010-01-23 19:20:23 Re: Miscellaneous changes to plperl [PATCH]