Networking/Ideas/NetworkManagerBugReporting

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.

The goal

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

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. Native settings (keyfile) and the D-Bus API would be also included.

Currently there is a component 'general' that is closest to this. It might be possibly renamed to 'core'. Ordinary users are expected to use this component whenever they don't know which one to choose. Other users or developers can then move the bug reports to the correct components.

• general (or core or something)

NetworkManager settings plugins (except keyfile)

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).

• settings (if downstream stuff is being maintained downstream)

Dynamic configuration

All stuff related to DHCP, IPv6 router discovery and possibly other generic means to negotiate configuration with external hosts.

• dynamic configuration

Wifi behavior

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.

• wireless

Mobile broadband

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

PPP

A bunch of specific issues.

• ppp

VPNs

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

Device drivers

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

CLI interface

Bug reports specific to CLI interface.

GUI stuff?

TODO: Check whether we have many GUI-related bug reports that can't be moved to other upstream project for a reason or another. Discuss how the NetworkManager project relates to the various GUI projects.

And more...

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.

Expected result

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.