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
Re: commit fests |
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: