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.
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.
But I don't like the idea of making a release out of it. Who would use
such a release? No one in production. Making a release comes with a
cost, even if it's just a dev release.
Agreed. That would have the opposite effect of what should happen.
I like the idea of having a sync point mid cycle, however, what I'd like
to see even more is an improved system in which we put less pressure on
the few committers we have, and give them more freedom to commit patches
they may not understand fully themselves by having an improved community
review and feedback process to give the patches the approval they need.
Doing so might allow us to keep the queue of a more or less fixed, short
length throughout the cycle. There would be a few advantages to this:
- The problem described above practically vanishes.
- Developers see their work accepted more quickly, giving them the
confidence to produce more.
- Developers are able to build on their earlier work, knowing that it's
believed to be reasonably sound, unlike now when they may not know for
months.
I believe we can achieve this with a couple of relatively minor changes:
1) *Slowly* introduce more committers. The are developers gaining
experience all the time, and as they become trusted by the existing
committers/core they can be 'promoted' to alleviate some of the pressure
on the existing guys.
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.
There are potentially a number of benefits to such a system:
- No patches will get lost
- Bruce's time is feed up from the mundane work of tracking patches, to
allow him to spend time developing, reviewing/committing and all the
other great jobs he does for the community.
- Status of patches can be seen at a glance.
- *All* discussion of a patch can be logged in one place, allowing the
committer to put more reliance on the knowledge and experience of his
peers, rather than being expected to fully understand the minutae of
every patch - thus allowing him to commit more.
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.
Regards, Dave
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
