[ovs-discuss] OVS Bug tracking

[Stokes, Ian]

> > At the last OVS-DPDK community sync meeting the issue of bug reporting
> > and tracking was raised. Specifically
> >
> > 1. What is currently available?
> > 2. Are there any improvements that can be made in the process?
> >
> > As it stands the process to follow is defined at:
> >
> > http://docs.openvswitch.org/en/latest/internals/bugs/
> >
> > An open vSwitch issue tracker repo has already been setup on GitHub at
> >
> > https://github.com/openvswitch/ovs-issues/issues
> >
> > From what I can see, the GitHub tracker seems to be used infrequently.
> Not sure if this is because it's not required to report bugs or that
> people are not aware of it?
> >
> > Is there a policy users should follow as regards reporting bugs on
> GitHub?
> >
> > Many groups will maintain their own internal bug tracking, I'm wondering
> would it be good practice to have people report known bugs in the GitHub
> tool?
> >
> > I see the pros and cons as follows:
> >
> > Pros
> >
> > 1. GitHub provides a common location to discuss bugs, this helps avoid
> duplication of effort as it can be easily flagged if someone is working on
> a patch for said bug.
> > 2. If used frequently then it will provide an accurate picture of what
> known issues are outstanding in OVS (easier then trawling through the
> mailing list).
> > 3. It could be used in conjunction with Patchwork to flag patches for
> review that are bug fixes. (I've read the patchwork allows a field to link
> to an external bug report url, I'm open to correction on this).
> >
> >
> > Cons
> >
> > 1. More overhead in general when creating the issue in GitHub when
> compared to reporting via email to the ML.
> >
> > What do others think? Is their value in formalizing the bug report
> process to use an external bug tracker?
> 
> As you say, there are pros and cons.
> 
> In my experience, bug trackers sometimes work well.  They can be a good
> way to keep track of issues that are outstanding and to collect
> information to figure out where those bug come from and try to find their
> root causes.  But this "best case' usually happens only when there is
> someone who considers it a priority to invest time in the bug tracker.
> Otherwise, you end up with problems caused by users who submit bug reports
> without checking for existing similar bug reports (which is often
> perfectly reasonable from the user's point of view) and who fail to follow
> up to requests for further information, by developers who consider that
> bug reports in the system can be fixed anytime they want and therefore
> there's no reason to follow up immediately, and by a general sort of rot.
> You can end up with situations where someone mentions a bug and they just
> get referred to the issue in the tracker, and no one really does anything.
> 
> The issues for simply reporting issues to a mailing list are to some
> degree the opposite.
> 
> In OVS, we have both options, but I think that the issue tracker is little
> known enough that few people actually follow it or file bugs there.
> 
> If you prefer to use the bug tracker, then it's there and I do try to
> follow along with the bugs filed there, and sometimes forwarding reports
> to the mailing list when it seems appropriate.  It's a reasonable idea to
> use it, and I don't want to discourage anyone from using it.

Thanks for the input Ben, this was discussed at the ovs-dpdk community call again since I first raised it and a few of the issues you mention came up.

There was confusion as to the purpose of this work so to clarify the goal of this is to simply be able to provide an accurate snapshot for the head of master in terms of known bugs.

There has been a suggestion to use the tool in with a reduced scope of ovs userspace bugs for a trial period and then a follow up review how useful it has been. If it is useful then it could be expanded to track bugs on a wider basis for OVS(bugs for different branches, kernel space bugs etc.) if there are resources to do so. If it's not useful then we can return to the way things are currently.

Would this idea be ok with you? In terms of putting resources towards the upkeep of bug tracking issues I'd be happy to help with this.

Also there was a query raised regarding the need/use of a tag with a bug ID to flag if a patch resolves a particular bug? Do you think that would be required/useful? 

Thanks
Ian