Branch Intelligence in Bugzilla

Max Kanat-Alexander mkanat at
Thu Jul 27 00:54:49 UTC 2006

	Some of us have been reading dbaron's message about management, here:

	When reading this and discussing it with Myk and LpSolit, I finally
came to the idea that Bugzilla should understand the idea of a "branch."

	Now, this idea has been proposed in the past, and I rejected it, saying
that it would make Bugzilla too complex. However, reading dbaron's
message, and thinking about my own bug list, I think it would be useful
in a lot of ways.

	Here's what I'm thinking:

	1) Make the Version field a multi-select.
	2) Associate each Version with a "Branch". For example, 1.8.1, 
           1.8.2, and 1.8.3 would all be associated with the "1.8
	3) For each affected branch, there would be two fields that 
           would appear on a bug:

		* Desire: ---, Unwanted, Would Take, Wanted, Required
		  Where "Required" would replace our current blocking 
		* Fix In: (Put all branch versions here)

	"Fix In" would represent both the version we plan to fix it in, and the
version it was actually fixed in.

	We could mark certain versions as "unreleased," so that they would show
up in the "Fix In" list, but not in the "Version" list.

	More than one branch could be associated with a version, so "alpha" and
"beta" could both be considered "branches" under this system.

	I think that would handle our current problems, and would make bug list
triage much more meaningful in a world with many branches.

	I think this would be worthwhile as a core Bugzilla feature because
nearly every open-source and corporate user of Bugzilla has some need
for Bugzilla to understand the idea of a "branch."

	(If you reply to this message from mozilla-dev-planning, make sure to
CC me directly since I'm not on the list.)

Competent, Friendly Bugzilla Services. And Everything Else, too.

More information about the developers mailing list