- 1 NetworkManager bug reporting
- 2 The goal
- 3 Upstream NetworkManager bugzilla
- 3.1 NetworkManager core behavior and fallback component
- 3.2 NetworkManager settings plugins
- 3.3 Dynamic configuration
- 3.4 Wifi behavior
- 3.5 Mobile broadband
- 3.6 PPP
- 3.7 VPNs
- 3.8 Connectivity checking and hotspot detection
- 3.9 Device drivers
- 3.10 CLI interface
- 3.11 Documentation
- 3.12 GUI stuff?
- 3.13 And more...
- 4 Fedora product at the Red Hat bugzilla
- 5 RHEL product at the Red Hat bugzilla (especially the public bug reports)
- 6 Expected result
NetworkManager bug reporting
Currently, the future feature planning is sort of common for NetworkManager upstream and Fedora. And mostly even for RHEL. Virtually all upcoming features are being discussed in public, then developed in public branches, then merged into the public master branch and eventually published in a public release.
We have no specific policy for reporting bugs, nor we have any internal rules how to handle the relations between various bugzillas and their products/components. This page serves as an informal proposal, or rather a place to gather information. Edit with care.
Many people visited Tom “spot” Callaway's talk about the user experience and the community. He devided the people into three levels of involvement (missed out regular developers for some reason).
- Users: We have plenty of them thanks to linux distributions and the userbase could very well provide us with some participants.
- Participants: We have lots of (potential) participants but they are scared by excessive complexity.
- Contributors: Existing participants won't become contributors again because of complexity of the project.
I believe the only way to get more participants and more contributors is to make our tools more accessible for them. And bugzilla is one of the most important tools we have.
Upstream NetworkManager bugzilla
It is located at http://bugzilla.gnome.org/. There is currently no strong reason to move the bugzilla anywhere else. There is a lot of collaboration between the NetworkManager project and the Gnome project at the desktop level.
Currently, I feel the biggest problem with bugzilla is the number of bugs one has to get through when working on NetworkManager. NetworkManager is being continually transformed from a former desktop component to a core system service. Therefore I believe we should:
- Specify which upstream software packages belong to the NetworkManager project and therefore are eligible for bugzilla bug reports.
- Have a number of well-defined components in the bugzilla to make it easy to concentrate on one specific area at a time.
The areas of interest follow…
NetworkManager core behavior and fallback component
This is the core behavior of NetworkManager. It consist of all those core modules like nm-manager, nm-device, and similar. It also includes nm-platoform, as it is not expected to have enough open issues to warrant a separate component. The same applies for all of the code for specific device types except those that are particularly problematic. Wired ethernet, bridges, bonds, teams, vlans and similar stuff would be included. D-Bus API would be also included.
This component would also continue to serve as a catch-all component for new bugs if the reporter cannot find a suitable component or if he just doesn't care.
NetworkManager settings plugins
One component for each plugin. Or it might be actually much better to handle this downstream and accept only bug reports with patches (using the core component).
- configuration (if downstream stuff is being maintained downstream)
All stuff related to DHCP, IPv6 router discovery and possibly other generic means to negotiate configuration with external hosts.
- dynamic configuration
There is a number of issues specific to wireless, most of them somehow related to wpa_supplicant or the kernel 802.11 stack. Any driver problems or hardware-specific bugs should be excluded.
Issues related to modems, phones and mobile connections. Again, it should exclude bugs specific to hardware drivers. Provider-specific stuff should probably be included. Would need more clarification.
- mobile broadband
A bunch of specific issues.
VPN stuff is specific enough to warrant a separate component.
- vpn (general stuff)
- vpn: openconnect
- vpn: openswan
- vpn: openvpn
- vpn: pptp
- vpn: vpnc
Connectivity checking and hotspot detection
Again, this is a very specific domain.
- connectivity detection
Problems in device drivers themselves. The outcome of these bug reports may be getting the drivers fixed, reporting to a more appropriate place, or even working around specific hardware/driver problems.
- device drivers
Note: Creating such a component would imply we're actually going to help with that stuff.
Bug reports specific to CLI interface.
- command-line interface
Bug reports related to the various documentation bits themselves.
nm-connection-editor and nm-applet should get their own bugzilla components.
I definitely forgot about something.
Fedora product at the Red Hat bugzilla
I personally think that this bugzilla should be only used for integration issues and trackers necessary for specific Fedora releases. The ifcfg-rh plugin might be a good example of integration tool.
RHEL product at the Red Hat bugzilla (especially the public bug reports)
There are some RHEL bug reports that are public for everyone to see. They may be occasionally interesting to Fedora, upstream or contributors.
The main component now called 'general' has about 120 bug reports once again, which is not easily managable. With the above components, it would have no more than 40 bug reports. After deleting obsolete/fixed ones, I believe there will still be like 30 bug reports. When we add some of our new plans to bugzilla, we will still have less than 40 of them.
Even though I still consider 40 to be too much, over the time, we fix some of them and possibly not as many new ones will appear, so we can oscillate somewhere about 20 in the long term, maybe?
But definitely contributors interested about wireless will be happy too, as they would find everything in one place. We have contributors who really specialize in autoconfiguration/DHCP. Those too would be happier. And the granularity is still reasonable so that we can actually manage that many components.