Message-ID: <46359E41.3030409@postgresql.org>
Date: Mon, 30 Apr 2007 08:44:01 +0100
From: Dave Page <dpage@postgresql.org>
User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326)
MIME-Version: 1.0
To: Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>
CC: Heikki Linnakangas <heikki@enterprisedb.com>,
	Simon Riggs <simon@2ndquadrant.com>, Bruce Momjian <bruce@momjian.us>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: Feature freeze progress report
References: <200704270313.l3R3DwF16449@momjian.us>
	<1177792836.3663.61.camel@silverbirch.site>
	<46349EF4.2010304@enterprisedb.com>
	<4634EC25.6010104@postgresql.org>
	<4634F25C.3070403@kaltenbrunner.cc>
	<4634FCFF.5040806@postgresql.org>
	<46358620.5080808@kaltenbrunner.cc>
In-Reply-To: <46358620.5080808@kaltenbrunner.cc>
OpenPGP: url=http://www.pgadmin.org/pgp/davepage.pgp
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Stefan Kaltenbrunner wrote:
> Interesting ... so if you have a new feature (or a number of them) -
> that is not directly depending on some sort of new backend feature - in
> pgadmin you "delay" it until the next postgresql mjor release ?

It's not so much that we delay the new features, it's just that we
follow the same development schedule, just with a shorter beta/feature
freeze period. We try to release just before PostgreSQL to avoid our
respective advocacy efforts trampling each other - but that's usually a
bit of a guessing game in itself!

> To be honest I personally have not used pgadmin in years and I have no
> idea what SQL-Server would be with or without Enterprise Manager so I
> actually don't really know enough to further speculate on this ...

I imagine the %age of SQL Server users that *don't* use Enterprise
Manager is close to zero. It's a platform on which everything is
expected to be a GUI.

>> Who's to say it will? Changes to pg_database have required a new release
>> in the past.
> 
> hmm true - but I imagine that a change to a catalog like pg_database is
> not the kind of feature you need to rush lot's of code in (again
> speculating here) ?

No, but it's exactly the reason why we release with/just before
PostgreSQL. If we were offset by six months, we might find ourselves
having to do compatibility releases mid-cycle for the latest PostgreSQL
release. A change in pg_database such as we had previously wouldn't be
an issue for the stable branch, but the changes to op classes etc. in
8.3 certainly would be of great concern.

>> I'm not specifically talking about complex patches (nor am I talking at
>> all about bug tracking) - there are a variety of patches in the queue,
>> of varying complexity. Some have been there for months, and worse, some
>> of them recieved little or no feedback when submitted leaving the
>> authors completely in the dark about whether their work will be
>> included, whether further changes are required, or whether they should
>> continue with additional enhancements.
> 
> that one I agree with - heck even people very close to the project are
> sometimes unclear about the status of this patch or that patch.
> Part of that could probably be solved by the simple tracker you are
> proposing - another way might be to promote more usage of the developer
> wiki.

Yep, true - though the reason I promote the use of the tracker is that
it could be implemented with minimal invasiveness into the existing
process, such that it automatically captures all discussion on the
topic, whereas I imagine some might object to repeatedly
visting/re-reading/editting a wiki to discuss a patch.

Regards, Dave