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