Re: Feature freeze progress report

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