Whilst evaluating Bugzilla, it became apparent that the flexibility of the product coul dbe greatly improved by the use of a component tree rather than a component list. This would allow a hierarchy of components to be generated dependant on the type of product that bugzilla is managing. For example, the product overview would look like this: Product Component Component ProductA Hardware Card A Card B Firmware Software Module A Module B Documentation This could be achieved in the components database by use of unique component ids in the components table, and each component having a parent_id field. We have already started to implement the changes to allow this functionality to be added (started work on 2.10 tho, so will take some time to merge with the current head). All code is backwards compatible with current bugzilla databases. I dont have much time left to complete the changes now, but I will get a patch here as soon as possible (my boss is breathing down my neck to get on with some company work now!) Any comments? Regards,

Yes, the current system does a few things based on the product/component distinction. Votes are distributed independently between products. Each product has a different milestone list. Probably more too ... Therefore a user might want to allow four levels (for example), where the first two consisted of the "product" and the last two of the "component". Are you just planning to keep the product as the top level? The way I was thinking of implementing this was simply putting component and product names like "A/B" or "A:B". Components are named similar to this right now on mozilla.org. In fact all that's really missing is that we need some support for querying on "A" instead of "A:B" on the query screen (which you can probably do already on the advanced section, but not on the product/component listbox). If you're proposing to do this differently, could you elaborate how it would work?

This does sound interesting. The method you suggest for storing it in the database makes perfect sense... but I'm curious how the user interface would work to choose a component that's a child of another one...

The component list of the query screen would include "A", "A:B" and "A:C".

This is not how I have it at present. How it works is a select box is shown for every level of the tree. It looks fine and works very well. (The look is exactly as shown in my first posting). The only place that the look is not correct yet is on the component editing page where the components are placed in the table alphabeticly. I dont have the time available at the moment to fix this, but I will look into it soon. One point to note here tho is that this change to bugzilla relies heavily on bug#43600 where I have submitted a patch to add unique keys to tables and reference those tables through this key (rather than the name of the component). I have not had any feedback on if this database change is making it into the head of CVS.

OK, so theoretically, if you choose a component that has children in a search, it would match any bugs that were in any of the child components also?

This is the way it works yup. Infact what it actually does is selects all the child components down the tree when a parent is selected. (this makes the query code easier to write).

Err, does that feature (selecting all the children) require JS in the browser? The general Bugzilla policy is that no JS is required from the browser but can be used for non-essential features.

The feature is a simple extension of the current JS used in 2.11. It will work fine without JS, but the children will have to be selected manually.

So then, what would happen if you selected just the parent? If you had to select all of the children, I don't really see what we're gaining here for the non-JS case. Anything?

If you are not using JS, then the system is not as easy to use. But it still gives you the advantage of a infinately more flexible component system that allows better management of projects. A display system that has less clutter in it in the component window. And, for the untrained, the ability to place a bug/feature in the correct place first time by following the tree down a logical route until they are unable to refine the location any further.

reassigning to me to consider for schema redesign

I think that finer grained component trees (supporting arbitrary depths) would make bug finding much easier, and I consider this the most important missing feature in the current Bugzilla system. Making meta-bug 65929 ("Make it easier to find bugs in Bugzilla") dependent on this one.

This information may be useful: http://www.dbpd.com/vault/9811/kamfn.shtml For each node in the (component) hierarchy, we have: - the node's ID (primary key) - the ID of its the parent node - two integer values L and R - other information like name, description, ... The L & R values determine a "range": B is a (transitive) subcomponent of A iff B.L (and B.R) is between A.L and A.R. Whenever a new node (component) is inserted in the hierarchy, all L & R numbers are re-computed: A counter (number-generator) is initialized, and the tree is traversed depth-first. When a node is entered, the L value is generated, then the children are processed, and when the node is left, the R value is generated. The set of R values and the set of L values thus have an empty intersection, and their union is an enumeration from 1 to the number of nodes in the tree. Code examples can be found there. I don't think there are any disadvantages.

Moving to real milestones...

Taking all Bugzilla 3.0 bugs -- congratulations to MattyT for the triage, it really was spot on. Note: I may end up pushing some of these bugs back to 3.2, we'll see. However, I believe all these bugs should just fall out of the redesign. Let's hope I'm right! (Note: I'm also resetting the priority field to "---" so that I can retriage any that I consider important or likely to be dropped.)

The Bugzilla 3 component is going away. We're going to depend on the Milestones for this. At the time this component was created, we didn't have milestones for Bugzilla.

*** Bug 92471 has been marked as a duplicate of this bug. ***

See also bug 156183, "crossreference components" (allow components to be in multiple parts of the heirarchy, like in dmoz).

Bailing on Bugzilla 3.0 due to too many other commitments.

*** Bug 291245 has been marked as a duplicate of this bug. ***

FWIW, I don't really like the idea of Component Trees. I've interviewed a few people who use bug-trackers that have Component Trees, and they all said it was more trouble than it was worth, for the admin. I suspect that it would also be more trouble than it was worth for us, the developers. :-)

Note this article on managing hierarchies in SQL: http://dev.mysql.com/tech-resources/articles/hierarchical-data.html

Still, there could be a bounded component hierarchy, like 4 or 5 levels max.

This isn't actually going to be implemented in Bugzilla 3.0.