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

Reply via email to