Description of problem: The problem right now: It is error-prone for release stream QE owners to assign the correct QA contact during the ACKing phrase due the complexity of the kernel subsystems. There were complains from other groups that assignment is wrong which hurts the testing phrase. The bless from someone who is more familiar with the code like developers is necessary to reduce errors. Other groups like kernel devel and virt group are also caring about kernel subsystem details and they used different approaches right now. It is a waste of efforts for several groups to implement something similar. The approach: The upstream bugzilla.kernel.org has the additional fields for subsystem when filing a kernel bug. The component is still kernel to match the source rpm, so there is no additional works for other parties like rel-eng and PM. This is what in the upstream kernel.org bugzilla, but there is no need to stick to it. ACPI: Bugs related to ACPI. Documentation: Documentation on the Linux kernel Drivers: Bugs related to device drivers. File System: Bugs related to file systems. IO/Storage: Bugs related to IO. Memory Management: Bugs related to memory management. Networking: Bugs related to networking. Other: Bugs against components that can not easily be classified in the other categories; such as modules and configuration. Platform Specific/Hardware: Bugs that are platform specific. Power Management: Bugs related to power management. Process Management: Bugs related to process management. SCSI Drivers: Bugs against SCSI drivers. Timers: Bugs related to timers. v4l‑dvb: Video for Linux Virtualization: Virtualization and each of subsystem can have the second-level sub-categories. Taking Networking for example, IPV4 IPV6 Netfilter/iptables Other Wireless The advantage are that it gives us fine-grained kernel subsystem responsibilities that make life easier for subsystem analyse, and clear boundary for subsystem testing responsibilities. In addition, those additional fields have been used in upstream already and are proved kernel subsystems and component details, so there is less work inside Red Hat to maintain the lists. As you can see from the Network components for example, it is fairly straightforward that can be re-used in different RHEL releases. Many devel folks have experiences working upstream that might already familiar with the kernel.org bugzilla interface. It takes time to make changes into Bugzilla, but it is going to help several groups in long term. Version-Release number of selected component (if applicable): 3.6.3+
There should be no extra work for developers as well. The worst case would be Unspecified for those categories which is the same workflow as we are having right now. Those are just extra details nice to have.
This will be really helpful - it would be nice to have for file systems, a break out for NFS, GFS2 and then the rest of the fs subtree can be "fs default" (or whatever). That would let us match the component with the QE team & our internal team....
Do not make wireless a sub category under networking, have it top level and have a separate top level entry for wired network drivers. Wired networking handles a huge volume of work so break it out accordingly.
Created attachment 469039 [details] screenshot from upstream
Created attachment 469040 [details] another screenshot from upstream
Created attachment 469041 [details] another screenshot from upstream
Hi CAI, Can you please explain more about what changes you would actually like to see in bugzilla? the screenshots you provided provide a list of products in the enter_bug.cgi and we have that in redhat bugzilla.. the other screenshot shows one field called kernel-version and we have the version field in bugzilla, and the last screenshot I am not sure what difference it has. Regards, Noura
Here is a simple draft version to be discussing with kernel managers under component kernel in BZ, == 1st level category == Storage Files Systems Network Wireless Scheduler Memory Management Process Management Power Management Desktop Virtualization Debugging/Tools Other == 2nd level category == * Storage: Multipath LVM Drivers Other * File Systems: NFS GFS Other * Desktop: Graphics Audio V4L Other * Debugging/Tools: Kexec/kdump Kprobe Ftrace Perf Other * Virtulization: Xen KVM Other
(In reply to comment #7) > Hi CAI, > > Can you please explain more about what changes you would actually like to see > in bugzilla? the screenshots you provided provide a list of products in the > enter_bug.cgi and we have that in redhat bugzilla.. the other screenshot shows > one field called kernel-version and we have the version field in bugzilla, and > the last screenshot I am not sure what difference it has. > > Regards, > Noura Hi Noura, What we want is this, When specifying kernel in the component field, it will give us an additional field called something like "Subsystems" or 1st level category whose content is still under discussing as mentioned in comment #8 plus "Unspecified" in case the reporter did not want to specify one. After specified any of the 1st level category, it will give us an additional field called 2nd level category to choose if there is any. Those screenshots just gave some ideas about upstream implementation which is different from what we have discussed here. Since our RHEL products is mapping components with SRPMS, the component can only be kernel. All those extra fields are only available after component kernel. CAI Qian
Hi CAI, for the fields that will appear based on the component. I would assume those fields will appear only in the RHEL products? and only if the component selected was kernel.. now when we have the first level category displayed , when the user selects a value from the first level category does the next list that appear will depend on the value selected? and the values in that 2nd level list will change based on the value selected from the 1st level? and so on ? or is it going to be a list of constant values that will always appear no matter what values are selected? Thanks, Noura
(In reply to comment #10) > for the fields that will appear based on the component. I would assume those > fields will appear only in the RHEL products? I'd add at least Fedora, so we can clone/bump bugs easily between the two.
Hi Noura, (In reply to comment #10) > for the fields that will appear based on the component. I would assume those > fields will appear only in the RHEL products? Yes, the original request is for RHEL. > and only if the component > selected was kernel.. now when we have the first level category displayed , > when the user selects a value from the first level category does the next list > that appear will depend on the value selected? and the values in that 2nd level > list will change based on the value selected from the 1st level? and so on ? or > is it going to be a list of constant values that will always appear no matter > what values are selected? Yes, the second level category will depend on the selection of the first level category. For example, if the 1st level category selection is "Storage", the 2nd level categories will be, Multipath LVM Drivers Other
Hi Cai, Implementing this is possible, I would say it can take up to 2 weeks of work. Is there a time in mind when you want this to be live? Cheers, Noura
Hi Cai, One question I would also like to ask is that do you think you will also require to add search related to those sub categories in the bugzilla search? and if you need to include it in the search do you think you will search for each sub category in each level separately? so for example you can say search for all bugs that has second level field equals "Multipath" ? Thanks, Noura
Hi Noura, (In reply to comment #13) > Hi Cai, > > Implementing this is possible, I would say it can take up to 2 weeks of work. > Is there a time in mind when you want this to be live? ASAP would be great. Thanks.
(In reply to comment #14) > Hi Cai, > > One question I would also like to ask is that do you think you will also > require to add search related to those sub categories in the bugzilla search? > and if you need to include it in the search do you think you will search for > each sub category in each level separately? so for example you can say search > for all bugs that has second level field equals "Multipath" ? Yes, search is required, and it would be useful to search for each sub category in each level separately.
Hi Noura, This is the latest version of the categories to be used. == 1st level category == Storage Files Systems Networking Wireless Scheduler Memory Management Process Management Power Management Desktop Virtualization Debugging/Tools Platform Enablement Other == 2nd level category == * Storage: Multipath LVM Drivers Other * File Systems: NFS GFS Other * Desktop: Graphics Audio V4L Other * Debugging/Tools: Kexec/kdump Kprobe Ftrace Perf Other * Virtulization: Xen KVM Other
Created attachment 470532 [details] the latest version of the categories Sorry Noura, please use this version attached with minor cleanup.
(In reply to comment #13) > Hi Cai, > > Implementing this is possible, I would say it can take up to 2 weeks of work. > Is there a time in mind when you want this to be live? Hi Noura, do we have any update? Thanks.
Created attachment 473196 [details] v2 of the categories Please use this new version. Diff is against the previous version: --- listv1 2011-01-13 11:26:04.613919080 +0800 +++ listv2 2011-01-13 11:26:48.206919002 +0800 @@ -28,6 +28,7 @@ Graphics Audio V4L +fbdev Other * Debugging/Tools:
(In reply to comment #19) > (In reply to comment #13) > > Hi Cai, > > > > Implementing this is possible, I would say it can take up to 2 weeks of work. > > Is there a time in mind when you want this to be live? > Hi Noura, do we have any update? Thanks. Hi Cai,, I have designed a solution for this feature.. and in the process of implementing.. there should be something for you to test by next week. Regards, Noura
Hi, I have added code in https://bz-web1-test.devel.redhat.com for this functionality, please test it and give us your feedback.. the only thing that is missing is the java script between selecting Kernel, first subsystem, second subsystem,, so the values of the subsystem menues are not dependent on each other yet. however I made those subsystem menues to appear only if the product has a component called kernel. I will be working on fixing the java script and making the menus depending on each other in the coming weeks due to work priorities. Thanks, Noura
Created attachment 478534 [details] v3 of the categories $ diff -u list.v2 list.v3 --- list.v2 2011-02-14 09:44:49.279625001 +0800 +++ list.v3 2011-02-14 09:43:52.233625001 +0800 @@ -1,6 +1,6 @@ == 1st level category == Storage -Files Systems +File Systems Networking Wireless Scheduler
A few comments: Please use the v3 version of the categories. Currently, it is possible to leave subsystem value empty. Can the system warn users to supply subsystems values if any of them is empty?
(In reply to comment #22) > Hi, > > I have added code in > > https://bz-web1-test.devel.redhat.com > > for this functionality, please test it and give us your feedback.. the only > thing that is missing is the java script between selecting Kernel, first > subsystem, second subsystem,, so the values of the subsystem menues are not > dependent on each other yet. however I made those subsystem menues to appear > only if the product has a component called kernel. I will be working on fixing > the java script and making the menus depending on each other in the coming > weeks due to work priorities. > > Thanks, > Noura Hi Noura, I just test the demo page, and one thing comes to my mind, could we add the subsystem column to the "Advance Search" page? As the purpose of subsystem is not only just pick it up when creating a bug, but also benefit people who using it to search a bug. Thanks.
Ric, one of suggest brought up during our group meeting is to put NFS/CIFS/AutoFS as a single sub-category under File Systems. Do you have any objection?
Hi Cai, I think that makes a lot of sense since they are quite related. Thanks!
Created attachment 479259 [details] v4 of the categories Please use this new version. --- v3 2011-02-17 11:25:18.566519004 +0800 +++ v4 2011-02-17 11:25:50.136519001 +0800 @@ -20,7 +20,7 @@ Other * File Systems: -NFS +NFS/CIFS/AutoFS GFS Other
Quick question. Do kernel folks think this list (currently at v4) might change frequently over time? Noura, will this content be editable by certain users or will new bugs be required to get the list updated?
(In reply to comment #29) > Quick question. > > Do kernel folks think this list (currently at v4) might change frequently over > time? It should not. This is pretty matching what it is in upstream. > Noura, will this content be editable by certain users or will new bugs be > required to get the list updated? Every change will be sent to Kernel Devel and QE stakeholders to discuss.
Hi Noura, where do we stand with this feature request? What's the rough ETA?
Hi David, I just started working on this again yesterday ,, This task is not that easy and will equire a lot hacking our existing code specially with the javascript work required to make the subsystem levels dependent on each other and dependent also on the component Kernel, At this stage I can not tell exactly what would the ETA be, but by the end of the week I should have an idea and I will let you know. Regards, Noura
Hi Noura, thanks for the info!
Hi Noura, another month, any update? :)
(In reply to comment #34) > Hi Noura, another month, any update? :) Hi. I'm taking over this project from Noura. I'll give an update in a fortnight or so once I have done some initial specification and design work.
(In reply to comment #28) > Created attachment 479259 [details] > v4 of the categories > > Please use this new version. > > --- v3 2011-02-17 11:25:18.566519004 +0800 > +++ v4 2011-02-17 11:25:50.136519001 +0800 > @@ -20,7 +20,7 @@ > Other > > * File Systems: > -NFS > +NFS/CIFS/AutoFS > GFS > Other Might it be better to also split out XFS and ext4 into their own subcategories? Right now we are prefixing bug titles with "[XFS]" or "[ext4]" to help separate them for search purposes. That, to me, say they should have their own sub-categories....
Dave, I created a new version to include your suggestion for everyone here to review.
Created attachment 515814 [details] v5 of the categories # diff -u v4 v5 @@ -22,6 +22,8 @@ * File Systems: NFS/CIFS/AutoFS GFS +XFS +ext4 Other * Desktop: @@ -36,6 +38,8 @@ Kprobe Ftrace Perf +EDAC +Oprofile Other * Virtulization:
Three things to note: * Component names must be unique for a product. You cannot have 'Other' multiple times, regardless of what level it is. * Component names are sorted alphabetically. 'Other' won't always appear at the end of the list. * The actual sub components don't need to be defined yet, although I'll be using the list for my development, and testing on the staging server. Once the code is live, you'll be able to request for the sub components to be added (this probably will happen two days after release in case any unexpected issues come up) -- simon
Created attachment 523468 [details] v6 of the categories This is the latest version of category. Diff against the previous version is below: @@ -2,7 +2,6 @@ Storage File Systems Networking -Wireless Scheduler Memory Management Process Management @@ -10,20 +9,39 @@ Desktop Virtualization Debugging/Tools +Platform Enablement +USB +Infiniband +Control Groups Other == 2nd level category == * Storage: -Multipath +dm-multipath +dm-crypt +Device Mapper LVM -Drivers +Storage Drivers Other * File Systems: -NFS/CIFS/AutoFS GFS XFS -ext4 +ext* +Btrfs +NFS +CIFS +AutoFS +Other + +* Networking +Protocol +IPv6 +IPSec +Netfilter +Wireless +NIC drivers +Bonding/Vlan/Bridge Other * Desktop: @@ -42,8 +60,7 @@ Oprofile Other -* Virtulization: +* Virtualization: Xen KVM Other
Would the sub components selection be a private or public?
*** Bug 218983 has been marked as a duplicate of this bug. ***
My bug from 5 years ago, seemed to have gotten dup'd here. After re-reading what I proposed back then and what is being proposed now, I can see how it would have turned into the mess which was created here. Eek. Considering the list of sub-components will always be in flux and never be settled upon. Heck it won't even be reliably useful unless people are pro-active at maintaining the sub-component field (which to be honest I doubt anyone will as bugs will straddle between multiple components). Why not just keep the sub-component super simple to reflect the current kernel group managers, ie hardware, general, filesystems, storage, virt, etc. If anything, that is useful for managers to claim their own bzs for further triaging later (considering every manager has their own way to triage bugs). It doesn't completely solve QEs problem but it might help narrow it down if they align their efforts towards kernel groups instead of sub-systems. On the other hand 5 years ago, when I was a wee lad maintaining a RHEL-5 kernel, there were two problems I was trying to solve One, trying to verify that all posted bzs were in fact kernel bzs was a pain because we had _three_ kernel components: kernel, kernel-xen, gfs2-kernel. This sucked. Luckily people stopped inventing new ones. I was hoping to combine these down to _one_ component and use sub-components to give finer granularity for manager's queries (ie xen, gfs2) Second, the other problem managers ran into was the vertical stack problem. For example GFS2 consisted of kernel and various userspace packages. The gfs2 manager at the time had to have multiple queries against all these packages to track his bugs. It would have been nice to use sub-components as a 'tag' for his packages. This would allow him to run _one_ query against sub-component/tag of say gfs2 and get all the results he wanted. Now obviously these problems are different from what Cai is trying to solve. But I believe the issues I was looking to solve are still relevant and might help expanding the scope of the solution. I also gave up on this feature long ago but decided to ride the wave of momentum (well mostly cooled off) of this bz and throw out my idea to see if it sticks. Cheers, Don
*** Bug 406511 has been marked as a duplicate of this bug. ***
I'm marking as closed as we've had no change since I worked on the bug last year, and I've had no requests to implement since. -- simon
Created attachment 614746 [details] v7 of the categories $ diff -u v6 v7 --- v6 2012-09-20 14:53:12.266880396 +0800 +++ v7 2012-09-20 14:53:52.497880985 +0800 @@ -2,9 +2,7 @@ Storage File Systems Networking -Scheduler -Memory Management -Process Management +Scheduler/Memory Management/Process Management Power Management Desktop Virtualization
Created attachment 634223 [details] split bonding with vlan and bridging per Rashid's feedback, split Bonding from vlan/bridging. --- bugsubcategory.v7 2012-10-27 11:00:56.810759513 -0400 +++ bugsubcategory.v8 2012-10-27 11:01:50.335636834 -0400 @@ -39,7 +39,8 @@ IPSec Netfilter Wireless NIC drivers -Bonding/Vlan/Bridge +Bonding +Vlan/Bridge Other
While the list in comment #65 seems reasonable. I need to understand how the component owner mailing lists would work before agreeing to this list. Networking, Desktop, and Kexec/kdump all have sub-components that are owned by multiple functional managers. Since Tim has often stressed there are 'no walls' on what people can do within the kernel team (and our team has always operated that way) we will need to offer more open-mailing lists for each component (and possibly sub-component), so any new bugs assigned to that subcomponent will be quickly noticed by possible component owners.
1. Sub-components that cover multiple areas could still default to kernel-mgr@ just like now. 2. Anyone who wants to follow several sub-components can be added to the default cc list for those sub-components. 3. The list of sub-components shouldn't be cast in stone - teams should be able to adjust them as and when they see fit. Either like Don says, go for a small number of broad categories initially, or just copy the same list that bugzilla.kernel.org uses.
Created attachment 786385 [details] v8 of the category v8 for minor change
--- cat.v7 2013-08-14 10:34:18.471370341 +0800 +++ cat.v8 2013-08-14 10:35:36.592536853 +0800 @@ -6,7 +6,7 @@ Power Management Desktop Virtualization -Debugging/Tools +Debugging/Tracing Platform Enablement USB Infiniband @@ -39,7 +39,8 @@ Netfilter Wireless NIC drivers -Bonding/Vlan/Bridge +Bonding +Vlan/Bridge Other * Desktop: @@ -49,7 +50,7 @@ fbdev Other -* Debugging/Tools: +* Debugging/Tracing: Kexec/kdump Kprobe Ftrace
I would like to re-iterate since groups/features are cross packages, i would need this to allow multiple sub-components with same name in same product (to avoid suffixing with meaningless 1|2|3|etc...) also, if there is anyway i can help push this effort (devel, testing, etc.) - please let me know. thanks, Itamar
(In reply to Itamar Heim from comment #75) > I would like to re-iterate since groups/features are cross packages, i would > need this to allow multiple sub-components with same name in same product > (to avoid suffixing with meaningless 1|2|3|etc...) Yes, my plan is to allow this since we aren't actually going to have sub components as such any more (which was why we had the restriction in the first place) and have a new drop down instead. Two questions I thought of this morning: 1) Would I be correct in the people that can edit this new field be the same as the people that can edit the component field itself (generally red hat associates, the reporter, assignee and qa/docs contacts)? 2) Is there any requirement that this new field be set at any stage (of the bug itself or the CDW process) for the kernel component?
1) I'd suggest yes - same security settings as component. 2) I'd suggest it's best left optional. If the original reporter doesn't know, they should just leave it blank - unless you want to have the field default to an 'Unknown' value.
Simon, I agree with Alasdair on both counts.
(Debate about whether to require a non-blank/"Unknown" value before the bug status reaches POST could follow once we see how it's being used and have adjusted the values available in the light of experience.)
It seems that a consensus has been reached, so adding this task to the 4.4 backlog, though it will be givn lower priority than the perfromance improvement work.
What's the estimated impact on page size, both for searching and bug creation?
(In reply to Florian Weimer from comment #83) > What's the estimated impact on page size, both for searching and bug > creation? For bug creation, there will be one extra row for sub components if the product has components with sub component. This row will be hidden if the user has Javascript enabled and the selected component(s) do not offer sub components. For the search, sub components will be a new multi-select field that appears after components (see the sample screen shot in the docs.engineering.redhat.com link). This field will _probably_ be hidden if the selected classification(s) and/or product(s) do not offer sub components, but that might change. -- simon
Adding to sprint10 so that work can begin, though there is one point of discussion that still needs to be resolved (whether selecting a subcomponent should be mandatory), and I expect that this task will take more than one sprint to be completed.
Question time. In the bug mails and show history page (including the inline history), how should multi level sub components be shown? For example, should Other and storage simply be shown as "Storage Other", or something else?
Should probably mention that if a bug has multiple components, and each of those have a sub component selected, the default assignee, qa contacts, etc will be one of those at random (which ever the browser sends first). Since it is unlikely that this will happen, it is kinda moot point.
could you provide some current screenshots of how this all looks in the browser atm (doesn't have to be pretty)? i'm thinking about the history question and the last 'moot point' you mentioned, but i'd like some visuals to get my head in the right place. For datamining purposes, i'm parsing activity history to recreate historical bug states; but given the terribly annoying fact that bz doesn't save the initial states of bugs into the activity history log, i have to first take the current value of a given field of interest, then work backwards in time mapping the adds/removes as things change. So just fyi atm, one way or another, i'll need to be able query and map the current value of bugs' subcomponents to be equivalent to the string value used in the activity log. Cheers!
(In reply to Chris Ward from comment #96) > could you provide some current screenshots of how this all looks in the > browser atm (doesn't have to be pretty)? No screenshots at the moment, since I haven't implemented the ability to edit sub components in existing bugs. That's next one the list. Once the code is completed (which I hope will be the end of next week), you'll all be invited to play with it. > i'm thinking about the history > question and the last 'moot point' you mentioned, but i'd like some visuals > to get my head in the right place. See above. It is not envisaged that there will be JBoss products (which allow you to have multiple components per bug) that also have sub components, but we've designed the system so that we can do this in case it is wanted. > For datamining purposes, i'm parsing activity history to recreate historical > bug states; but given the terribly annoying fact that bz doesn't save the > initial states of bugs into the activity history log, i have to first take > the current value of a given field of interest, then work backwards in time > mapping the adds/removes as things change. > > So just fyi atm, one way or another, i'll need to be able query and map the > current value of bugs' subcomponents to be equivalent to the string value > used in the activity log. This should work, as the 'sub component' field is just like any other field, so the history can be used to work backwards (with the same restriction as other fields if the sub component name is changed by an admin)
sounds good; i'll hang tight then till you get things into a state i can test it directly. Cheers!
Very nice! When changing subcomponent in an existing bug, it would be useful if the checkboxes for resetting asignee/qa contact to the default for the subcomponent appeared (like when changing the component).
"Redisplay table with bug counts (slower)" when displaying the list of subcomponents has no effect. - Fix or disable? "A sub component cannot have itself as a parent component." - Perhaps remove the sub component being edited from the drop-down list so it can't be selected. Bottom of subcomponents edit screen: Edit component 'lvm2' or edit other components of product 'Red Hat Enterprise Linux 6', or edit product 'Red Hat Enterprise Linux 6'. - Perhaps also add a direct link to "edit other sub components of component 'lvm2'" ?
This change is now live. If there are any issues, do not reopen this bug. Instead, you should create a new bug and reference this bug. -- simon
Fixed in version: 4.4.1012 but was not mentioned in Bugzilla main page, Version 4.4.1012 Bug 1010563: Add mail-headers "Precedence: bulk" and "Auto-Submitted: auto-generated" Bug 1020897: Strange results when including "URL" column in results. Also tested in the production, seems not work. What do you mean by this was now live?
(In reply to CAI Qian from comment #166) > Fixed in version: 4.4.1012 > > but was not mentioned in Bugzilla main page, Not all bugs that are changed are mentioned on the homepage. While the code has gone live, the Release Solution team have decided to keep this feature disabled until the week beginning January 20th. As per comment 165, any new requests for changes should be made in a new bug rather than reopening this bug. https://partner-bugzilla.redhat.com/ still has sub components enabled (except for a short period this morning), so you can continue to do any last minute testing.
This change is now live on the production server. Obviously it will required the appropriate teams to create the sub components for components before it can be used. Just a reminder, if there are any issues, do not reopen this bug. Instead, you should create a new bug and reference this bug.