Andi Gutmans ([EMAIL PROTECTED]) wrote:
> features (also because it has enough additional features already which are 
> enough for another minor version), but the developers need to actually go 
> through the bugs database and work on those crash bugs. It's not that easy 
> to get everyone to work on them.

The Debian project uses a practice which may be useful.

Bugs are identified by project leaders as release-critical. 
Release-critical is a bug severity level which bugs (crashers,
cosmetic, whatever) can get promoted to.

There's a page giving stats on RC bugs:

And approximately monthly bug squashing parties held on IRC:

My suggestion, having watched a few open-source projects structured
similarly to PHP, is to declare a particular date as a freeze date,
with pressure NOT to commit major overhauls increasing as the freeze
approached.  At the freeze, a CVS branch is created and the bug
squashing party begins - release critical bugs only!

Once RC bugs get cleared, the branch changes get merged back into the
mainline and development resumes until it's time to release again.

PHP Development Mailing List <>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Reply via email to