Received: from localhost (maia-5.hub.org [200.46.204.182])
	by postgresql.org (Postfix) with ESMTP id 5BD3D9FB2DE;
	Mon, 30 Apr 2007 04:46:26 -0300 (ADT)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.182]) (amavisd-maia, port 10024)
	with ESMTP id 03238-09; Mon, 30 Apr 2007 04:46:19 -0300 (ADT)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.4
X-Greylist: from auto-whitelisted by SQLgrey-1.7.4
Received: from svr2.hagander.net (svr2.hagander.net [88.198.128.226])
	by postgresql.org (Postfix) with ESMTP id 16E3A9FB274;
	Mon, 30 Apr 2007 04:46:22 -0300 (ADT)
Received: by svr2.hagander.net (Postfix, from userid 1000)
	id 1CF5DDCC8C0; Mon, 30 Apr 2007 09:46:21 +0200 (CEST)
Date: Mon, 30 Apr 2007 09:46:21 +0200
From: Magnus Hagander <magnus@hagander.net>
To: Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>
Cc: Dave Page <dpage@postgresql.org>,
	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
Message-ID: <20070430074621.GA13100@svr2.hagander.net>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <46358620.5080808@kaltenbrunner.cc>
User-Agent: Mutt/1.5.11
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200704/1226
X-Sequence-Number: 102559

On Mon, Apr 30, 2007 at 08:01:04AM +0200, Stefan Kaltenbrunner wrote:
> Dave Page wrote:
> > Stefan Kaltenbrunner wrote:
> >>> This means that there is a huge rush of new code in pgAdmin's
> >>> development cycle, right at the time when we should be testing - making
> >>> the release process more and more rushed as each release of PostgreSQL
> >>> gets more efficient and adds more and more new features.
> >> this is indeed an issue - but there is nothing that says that pgadminIII
> >> has to support all the new features of a backend the they it get
> >> released. pgadmin is decoupled from the min development cycle anyway so
> >> adding support for a new features a few months later sounds not too much
> >> an issue.
> > 
> > No it's not decoupled; it runs almost exactly in sync. Our most popular
> > platform ships with pgAdmin as standard because thats what the users of
> > that platform expect. Not shipping with pgAdmin (or a functionally
> > complete one) would be like shipping SQL Server without Enterprise Manager.
> 
> 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 ?

Yes.


<snip>


> > 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.

The advantage of a "proper system" would be that it'd be consistent. Using
the wiki could get very unstructured (unstructured being a *feature* of a
wiki). A specialised system will be able to enforce how things look and are
worked with, and makes the *use* of the system easier. Using the wiki makes
installing it easier, since it's already there, at the cost of usage.

//Magnus