Received: from magus.postgresql.org (magus.postgresql.org [87.238.57.229]) by mail.postgresql.org (Postfix) with ESMTP id 6F50DCB73DC for ; Sun, 8 Apr 2012 19:17:16 -0300 (ADT) Received: from smtp.01.com ([199.36.142.181]) by magus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1SH0Q3-0000UI-IE for pgsql-hackers@postgresql.org; Sun, 08 Apr 2012 22:17:15 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id E56133F53FF for ; Sun, 8 Apr 2012 17:16:56 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ufqCFakEy7Q2 for ; Sun, 8 Apr 2012 17:16:56 -0500 (CDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id C63C03F5593 for ; Sun, 8 Apr 2012 17:16:56 -0500 (CDT) Received: from Sidney-Stratton.local (70-36-143-92.dsl.dynamic.sonic.net [70.36.143.92]) by smtp-out-1.01.com (Postfix) with ESMTPSA id 6A2873F53FF for ; Sun, 8 Apr 2012 17:16:56 -0500 (CDT) Message-ID: <4F820E52.3040006@agliodbs.com> Date: Sun, 08 Apr 2012 15:16:50 -0700 From: Josh Berkus Organization: PostgreSQL Experts Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: pgsql-hackers@postgresql.org Subject: Re: Last gasp References: <1333651599.31440.47.camel@hvost> <1333653659.31440.68.camel@hvost> <1333655785.15576.13.camel@hvost> <4F7E99BA.1080805@2ndQuadrant.com> <8687.1333833601@sss.pgh.pa.us> <4F80C552.5080606@dunslane.net> <13916.1333854195@sss.pgh.pa.us> In-Reply-To: <13916.1333854195@sss.pgh.pa.us> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -1.9 (-) X-Archive-Number: 201204/364 X-Sequence-Number: 206167 > In short, the idea of strongly calendar-driven releases looks more > and more attractive to me the more times we go through this process. > If your patch isn't ready on date X, then it's not getting into this > release; but there'll be another bus coming along before long. > Stretching out release cycles to get in those last few neat features > just increases the pressure for more of the same, because people don't > know how long it will be to the next release. As you know, I've supported this view for several years. > Just to be clear ... I don't believe that we can have hard-and-fast > *release* dates. I am suggesting that it might be a good idea to have > a hard deadline for committing new features. But beta test phase will > take however long it takes. I don't think shaking out bugs is a > predictable process. It could have more visibility though, which would probably also make it go faster. Something to work on. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com