Description of problem: The kernel has the unusual case that it has different maintainers for different parts of the kernel. Considering the kernel is too big for one person to have enough in-depth knowledge to accept or reject patches, the sub-components are broken down to more managable chunks (ie scsi, usb, network, fs, etc). Currently the kernel maintainers browse a bug and based on the subsystem, they look on their list and re-assign the bug to the appropriate sub-subsystem maintainer. Unfortunately, with all the other responsibilities the kernel maintainer has, this becomes a bottleneck and sometimes developers can go days or weeks without seeing the bugzilla. One idea I had to speed this up was to create a new bugzilla field, "sub-component". The idea here is to allow the bug reporter to narrow the kernel down to a particular sub-component (if they choose to do so) and have bugzilla automatically assign the bug to the sub-component maintainer (very similar to what is currently done with the "component" field). I am hoping this would filter bugs to the appropriate people faster, relieving some of the bottleneck. While not perfect, it should have some positive impact. Thoughts? Is this doable?
Due to the new cvs check-in criteria, it has been difficult to check posted patches into the kernel. Scripts were created to relax this criteria and allow kernel patches in the POST state to automatically be approved for 5.1. However, various kernel groups (and customers) select components other than 'kernel' to categorize their bugs. For example, 'kernel-xen' and 'gfs2-kernel'. Now I can continue to request those categories be included in the 'exception' path of the cvs check-in policy. But it seems silly to constantly have to file bugzillas for something like this every time an issue pops up. The counter argument is to have every one file under 'kernel'. But because the kernel is soooo big, it makes life difficult for managers to extract statistical reports for their kernel sub-group. Therefore this bugzilla is becoming extremely urgent to get resolved, otherwise my life becomes a living hell!! Please let me know how fast you guys can implement this.
Does this bug still need to be address as you originally reported it? Any updates? I'm interested in having a sub-component field added to Bugzilla as well. I'm thinking that they could even be 'tags' that are defined on the fly by whom-ever is reporting the bug. A list of existing tags would be shown, but the option to add a new tag would be provided (perhaps only to @redhat.com + maybe partners). This would take the overhead down to a minimum for implementation. Or, of course we could go through each component individually and assign 'best-guesses' for sub-components, but that would be a head-ache and it would take many more months I'm sure... It would be *very* useful in terms of tracking more detailed defect/feature metrics. We could also visualize trends of customers/partners interest/concern this way from a new perspective. And see component/sub-component risk more clearly too.
Tags are an interesting concept. I think the word I used 'sub-component' doesn't accurately describe what I wanted, but tags does. My original frustration was there were two different ways to look at a bug. The first from a horizontal perspective, ie any change in the kernel was assigned 'kernel' component. The second perspective was from a vertical one, ie any change related to the gfs-cluster suite (userspace or kernel) would be assigned 'gfs' component. As it is right now a bugzilla can only be assigned one component, which makes it hard for various groups to accurately categorize their bugs. Putting 'tags' on the bugs and being able to search based on that would work great (I'm thinking 'tags' the way gmail has set them up) where any bug can have multiple assignments to them. Of course 'tags' scale better and have other fun benefits like the ones you described above. Also we can probably finally get rid of tracking bugs!! As they would just be another 'tag'.
This may be possible with the new Bugzilla. If you look at the bottom of the page in the footer there is a new Tagging field that you can use to tag bugs you want to find later. If you are looking at a bug, it will automatically fill in the current bug id in the bugs field. If you are not looking at a bug, you can still use the tag feature by filling in the bug id. Technically the tags are the same as stored searches, so they are shareable to others as well. If you go to Preferences->Saved Searches, you will see your new tag name in the search list. There you can share it with a particular group of people. So in theory yes it could replace blocker bugs since it would be an easy way to group a list of bugs under a specific tag name. You can also have multiple tags for a bug as well. Do you think this would be sufficient for this issue? Dave
I guess I was envisioning more of a drop down list of tags that people could select from. Because as an individual, I have no idea what tags already exist. It's like leaving the component field empty and having people type in the component they have a problem with. You wind up with interesting results. Also I was hoping the 'tag' feature would be more front-n-center rather than tucked away at the bottom. For example, if you ever use gmail, they make it easy and intuitive to tag email messages. I was hoping to have that here. Also if we want to make extensive use of 'tagging' then we might as well get rid of the 'component' field because it would be irrelevant. So I guess I was trying to find an easy way for people when they create bugzillas to intuitively go and tag the bug as say 'kernel', then at the same time quickly tag it 'gfs' too, and add any other relevant tags. Then later on management or a developer could quickly add their tags too (either individually or as a collection of bugs) Thinking about it for a bit, perhaps the quickest way to understand what I was look for in a concrete way, is to imagine the following - take what we have now and replace the word 'component' with 'tag' - keep the same 'component' drop down list for 'tag' but every time you select the 'tag' you want, create another *new* 'tag' field with the same drop down list right below it (giving people the option to add another tag). - this would allow people to understand they could mark each bug with multiple tags and would be in a normal spot where it wouldn't affect their normal bugzilla workflow. Does that make sense? I still don't know how easy it would be to implement though but that is the idea. Of course, all this needs to be accessible from xmlrpc. :-)
FWIW, anyone can go to their Preferences->Saved Searches and see all of the tags/searches that they can access from a single page so it is not too far from what you were envisioning. It is just not on the bugs themselves. Dave
*** This bug has been marked as a duplicate of bug 653316 ***