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

Dave Page wrote:
> Heikki Linnakangas wrote:
>> I like the idea of draining the patch queue mid-way through the
>> release cycle. That'll hopefully encourage people to submit patches
>> earlier in the release cycle, knowing they will be reviewed. It'll
>> also give people working on external projects, drivers and tools, a
>> checkpoint to sync with.
> 
> This is important for me - the pgAdmin development cycle follows that of
> PostgreSQL's for very obvious reasons, however *after* we enter 'feature
> freeze' we can still end up adding significant amounts of new code. Why?
> Becvause during PostgreSQL's feature freeze, patches are applied which
> add new functionality we need to support. We can't code for the new
> features when patches are submitted because we don't know if they'll go
> in, or how much they'll change when they do.
> 
> 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.

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

[...]

> 2) Introduce a new patch management system. I suggest a web interface
> through which patches be submitted. This would assign them an ID number,
> and forward them to the patches list. The system would track any
> responses to the initial email, logging the thread automatically and
> making it available through the web interface. Posts from
> trusted/experienced developers might be highlighted so that committers
> can see at a glance if any of the more experienced guys have commented
> on the patch yet. A status flag could easily include a status flag to
> mark them as "won't accept", "committed", "under review" or "under
> revision". If left at "under review" for too long, the patch might be
> highlighted, and if at "under revision" for too long, the patch author
> might be automatically requested to send a status report.

this sounds like trying to reinvent a real bugtracking system with an
email interface ...

[...]

> Well, I'll stop there as this is getting long winded - I'm sure others
> will have their own ideas about how we can improve our processes for
> future releases; one thing I'm certain of though, is that we absolutely
> must strive to improve them somehow as whilst they has served us well in
> the past, the current process is starting to show that it just won't
> scale as the project grows.

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


Stefan