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
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
