On Tue, May 02, 2017 at 04:59:40PM +0000, Stokes, Ian wrote:
> > > 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.
I'm OK with it, but I'm probably not going to invest a lot of time in it
myself.
> 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?
We have a tag for that:
``Reported-at: <URL>``
If a patch fixes or is otherwise related to a bug reported in
a public bug tracker, please include a reference to the bug in
the form of a URL to the specific bug, e.g.:
::
Reported-at: https://bugs.debian.org/743635
This is also an appropriate way to refer to bug report emails
in public email archives, e.g.:
::
Reported-at: http://openvswitch.org/pipermail/dev/2014-June/040952.html
_______________________________________________
discuss mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
