Bug 218983 - [feature] new bugzilla field -> sub-component
[feature] new bugzilla field -> sub-component
Status: CLOSED DUPLICATE of bug 653316
Product: Bugzilla
Classification: Community
Component: Bugzilla General (Show other bugs)
devel
All Linux
urgent Severity medium (vote)
: ---
: ---
Assigned To: PnT DevOps Devs
Kevin Baker
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-12-08 16:30 EST by Don Zickus
Modified: 2014-12-01 18:08 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-11-29 21:43:26 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Don Zickus 2006-12-08 16:30:22 EST
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?
Comment 1 Don Zickus 2007-03-14 18:16:38 EDT
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.
Comment 2 Chris Ward 2008-08-15 08:11:46 EDT
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.
Comment 3 Don Zickus 2008-08-15 10:00:45 EDT
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'.
Comment 4 David Lawrence 2008-08-15 12:20:51 EDT
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
Comment 5 Don Zickus 2008-08-15 13:14:02 EDT
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. :-)
Comment 6 David Lawrence 2008-08-15 15:17:50 EDT
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
Comment 8 Simon Green 2011-11-29 21:43:26 EST

*** This bug has been marked as a duplicate of bug 653316 ***

Note You need to log in before you can comment on or make changes to this bug.