John Donagher ([EMAIL PROTECTED]) wrote:
> Someone mentioned the idea of bug-squashing parties; I think that's a great
> idea, although since the project's developers are all over the world it may be
> a little tricky to organize (I'm not fixing bugs at 10AM).
Debian's bug parties are weekend-long affairs. Start Friday, end
Monday morning.
> But I'm really not
> in favor of adding more process.
It's more of a social process than an explicit development process.
The only extra "process" is a new severity level in their bug system,
to indicate that bug must be resolved for release to occur. It's not
zero-defects, it's zero release-critical defects.
People just yell "bug party!" maybe invite some friends over and start
hacking. Everyone in an IRC channel.
> Personally, I've never seen adding steps to a
> development process actually help development. It seems like instead of voting,
> maybe QA people (as well as developers) should have ability to set priorities
> on bugs (although these are arguably very subject to perspective).
The mozilla project allows members of the public to "vote for" a bug to
indicate that it's bad and annoying to them. This can be used as input
to determining that a bug is RC.
Along other lines, we could play platform favourites and say that
anything that reproducibly crashes an x86, ppc, or alpha system is RC.
It's all squishy heuristics, and until we start playing with it we'll
never know what works.
--
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]
