Re: Feature freeze progress report - Mailing list pgsql-hackers

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

> 
>>> Sooner or later with things working the way they are now, we *will*
>>> reach a breaking point at which pgAdmin simply won't be ready when
>>> PostgreSQL is released.
>> well if it still works but does not yet support $wizzbangnewfeature that
>> sounds ok too me ?
> 
> 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) ?

> 
>> this sounds like trying to reinvent a real bugtracking system with an
>> email interface ...
> 
> More or less - but one that's simple by design, and specifically for
> tracking what happens with our patches with the absolute minimum amount
> of change required to our existing communication methods.

ah - ok

> 
>> not sure I fully agree here - I think we could do a bit better on the
>> "bug tracking front" but it is a bit unclear if we cn honestly sy that
>> "the current process" does not work or is not going to scale in the
>> future. Complex patches need time - sometimes much more time than a
>> release or even two release cycles - 
> 
> 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.


Stefan