From: | Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc> |
---|---|
To: | Dave Page <dpage(at)postgresql(dot)org> |
Cc: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Feature freeze progress report |
Date: | 2007-04-29 19:30:36 |
Message-ID: | 4634F25C.3070403@kaltenbrunner.cc |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-www |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Akmal Akmalhojaev | 2007-04-29 19:37:09 | Programming new commands problems. |
Previous Message | Dave Page | 2007-04-29 19:04:05 | Re: Feature freeze progress report |
From | Date | Subject | |
---|---|---|---|
Next Message | Marc G. Fournier | 2007-04-29 19:51:53 | Re: Ancient Binary versions ... |
Previous Message | Dave Page | 2007-04-29 19:08:15 | Re: Ancient Binary versions ... |