Re: Feature freeze progress report

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.

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

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

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

it's unclear if trying to get those
> in more agressively (by having more commiters or applying them earlier)
> might not actually cause more harm due to -HEAD getting less stable and
> causing developers to spend time hunting regressions.

I'm not advocating committing patches that might destabilize the code,
I'm suggesting making it easier for individual committers to make use of
the knowledge and experience of everyone else in the community, whilst
at the same time reducing the reliance on their own experience. Even now
we occasionally see patches getting committed that (for example) Tom has
rejected months earlier. At the very least a tracker should help prevent
that happening, at best it will help committers work faster and more
effectively because they have all the relevant discussion in front of them.

Regards, Dave.