X-Original-To: pgsql-hackers-postgresql.org@postgresql.org Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id 14CD69FA103 for ; Wed, 6 Sep 2006 21:16:16 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 92195-09 for ; Wed, 6 Sep 2006 21:16:04 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from mailbox.samurai.com (mailbox.samurai.com [205.207.28.82]) by postgresql.org (Postfix) with ESMTP id 38D5D9FA4F4 for ; Wed, 6 Sep 2006 21:16:05 -0300 (ADT) Received: from localhost (mailbox.samurai.com [205.207.28.82]) by mailbox.samurai.com (Postfix) with ESMTP id A615A61D1A; Wed, 6 Sep 2006 20:16:03 -0400 (EDT) X-Virus-Scanned: by amavisd-new at mailbox.samurai.com Received: from mailbox.samurai.com ([205.207.28.82]) by localhost (mailbox.samurai.com [205.207.28.82]) (amavisd-new, port 10024) with LMTP id s4onqFqn30AP; Wed, 6 Sep 2006 20:16:02 -0400 (EDT) Received: from [192.168.0.103] (d226-88-230.home.cgocable.net [24.226.88.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailbox.samurai.com (Postfix) with ESMTP id EB1B261D14; Wed, 6 Sep 2006 20:16:01 -0400 (EDT) Message-ID: <44FF64BF.2060001@samurai.com> Date: Wed, 06 Sep 2006 20:15:59 -0400 From: Neil Conway User-Agent: Thunderbird 1.5 (Macintosh/20051201) MIME-Version: 1.0 To: Bruce Momjian CC: Robert Treat , pgsql-hackers@postgresql.org, Tom Lane , Greg Sabino Mullane Subject: Re: Postgres tracking - the pgtrack project References: <200609021606.k82G6Ft00398@momjian.us> In-Reply-To: <200609021606.k82G6Ft00398@momjian.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200609/616 X-Sequence-Number: 90145 Bruce Momjian wrote: > Robert Treat wrote: >> FWIW I have never understood why we don't require patch submitters/committers >> to update the release notes when they do the patch. I've suggested this more than once in the past -- I think it would be a clear improvement over the status quo. Updating the release notes incrementally would lead to more accurate and complete release notes: more accurate because the description for a feature would be written at the same time as the feature itself, and more complete because it would be harder to unintentionally omit discussion of a new feature. It would also help communicate to users what features will be in the next release of Postgres, which is certainly good from a PR point of view (a certain Swedish software company is very fond of talking about the features it will be adding in future releases, for example...) Finally, it would remove the need for a sequential scan of the CVS history, which I'm sure is pretty time-consuming, and delays the beta process. > I can't even get documentation for many patches. I am hesitant to add > even more burden. I would prefer they concentrate on documentation. The first revision of a patch often doesn't include documentation updates, but in that case the submitter should be promptly told what they need to fix; I think the same would apply here. In practice, if you're committing a patch, you *should* understand it well enough to write a release note entry for it, so the burden might end up falling on committers, anyway. -Neil