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 ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
