Peter M. Goldstein wrote:
Thanks for clarifying what you mean and the benefits (you may have said the same thing, but with the context it clarified for me at least).As I made clear in my previous email, I've got no objection to recording alpha, beta, and rc data in the bug system. I think it's valuable. But preserving the ability to simply query and organize bugs by major version dictates that the two be kept apart. It also simplifies milestone, alpha, and beta release since by using a product of several fields ( major version (2.1, 3.0) * minor version (a1, a2, a3, a4, a5, b1, b2, b3, b4, b5, rc1, rc2, rc3, rc4, rc5, 0, 1, 2, 3, 4, 5)) it no longer becomes necessary to alter the bug system everytime an alpha, beta, or milestone is released.
Is there any interest in considering something like JIRA? We've started using it for some internal projects and will probably migrate all our company's projects from bugzilla to JIRA in the next couple of months. It's much less confusing and can customize the extra fields. I've started to see other OS project (none that I know of from jakarta yet). anyway, thought I'd mention it.Not really. How many bugs were fixed in 2.1? How many of those bugs were recorded in Bugzilla? Maybe 10%? Tops. Doesn't sound very useful to me.Part of this is cultural, but a lot of it is that the bug system is confusing and lacks fields that describe the current situation.
Thanks for being so passionate about release management. It's really valuable.Aaron's recent comments on release management, while a bit strong, are most well taken. A conversation on proper version/release control is probably in order shortly. The conclusions of such a discussion should be recorded for future reference, so conversations like this and the earlier version number discussion become unnecessary.
--
Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
