Open Bug 43940 Opened 24 years ago Updated 13 years ago

Component trees

Categories

(Bugzilla :: Bugzilla-General, enhancement, P3)

Product:
Bugzilla
Component:
Bugzilla-General
Type:
enhancement

Tracking

()

People

(Reporter: mbs, Unassigned)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

(Whiteboard: Schema Consideration) 

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".
Depends on: 43600
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
Assignee: tara → cyeh
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.
Blocks: 65929
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.
Whiteboard: 3.0 Schema Consideration
Moving to real milestones...
Whiteboard: 3.0 Schema Consideration → Schema Consideration
Target Milestone: --- → Bugzilla 3.0
Assignee: cyeh → ian
Component: Bugzilla → Bugzilla 3
Priority: P3 → --
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.
Component: Bugzilla 3 → Bugzilla
*** Bug 92471 has been marked as a duplicate of this bug. ***
Severity: normal → enhancement
Priority: -- → P3
Component: Bugzilla → Bugzilla-General
OS: Linux → All
Product: Webtools → Bugzilla
Hardware: PC → All
Version: other → unspecified
See also bug 156183, "crossreference components" (allow components to be in
multiple parts of the heirarchy, like in dmoz).
Blocks: 156183
Bailing on Bugzilla 3.0 due to too many other commitments.
Assignee: ian → nobody
Assignee: nobody → nobody
Depends on: 280122
*** 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. :-)
Still, there could be a bounded component hierarchy, like 4 or 5 levels max.
QA Contact: mattyt-bugzilla → default-qa
This isn't actually going to be implemented in Bugzilla 3.0.
Assignee: nobody → general
Target Milestone: Bugzilla 3.0 → ---
You need to log in before you can comment on or make changes to this bug.