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:
http://master.debian.org/~wakkerma/bugs/
And approximately monthly bug squashing parties held on IRC:
http://lwn.net/2001/0222/a/db-bugsquash.php3
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 <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
