public inbox for [email protected]
help / color / mirror / Atom feedFrom: Magnus Hagander <[email protected]>
To: Stefan Kaltenbrunner <[email protected]>
Cc: Dave Page <[email protected]>
Cc: Heikki Linnakangas <[email protected]>
Cc: Simon Riggs <[email protected]>
Cc: Bruce Momjian <[email protected]>
Cc: PostgreSQL-development <[email protected]>
Subject: Re: Feature freeze progress report
Date: Mon, 30 Apr 2007 09:46:21 +0200
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
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
view thread (98+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Feature freeze progress report
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox