public inbox for [email protected]
help / color / mirror / Atom feedFrom: Stefan Kaltenbrunner <[email protected]>
To: 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 10:07:52 +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]>
<[email protected]>
Dave Page wrote:
> 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!
ah ok - makes sense
>
>> 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.
I will take your word on that - Iäm neither a Windows nor a MSSQL Server
user :-)
>
>>> 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.
hmm - understood. I guess I simply speculated that doing a pgadmin
release might be much more lightweight than doing a PostgreSQL release
(how many "backbranches" is pgadmin supporting?". I think I now
understand why you are doing it that way though ...
>
>>> 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.
you are probably right here too - though I can see some value in a wiki
too. Some things that come to mind are subproject specific todo
lists(like the XMLTodo) or the Wishlist (which is a rather abstracted
thing to point people to that ask "what can we expect in $release if we
are really really lucky" and don't want to parse the pgpatches list
bruce keeps)
Stefan
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]
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