Re: commit fests - Mailing list pgsql-hackers

From Greg Smith
Subject Re: commit fests
Date
Msg-id 4B5B4D21.5060109@2ndquadrant.com
Whole thread Raw
In response to Re: commit fests  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Responses Re: commit fests  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: commit fests  (Bruce Momjian <bruce@momjian.us>)
List 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@2ndQuadrant.com  www.2ndQuadrant.com



pgsql-hackers by date:

Previous
From: Alex Hunsaker
Date:
Subject: Re: Miscellaneous changes to plperl [PATCH]
Next
From: "David E. Wheeler"
Date:
Subject: Re: Miscellaneous changes to plperl [PATCH]