Kashyap Chamarthy <kcham...@redhat.com> wrote on 03/18/2016 07:28:09 AM:
> From: Kashyap Chamarthy <kcham...@redhat.com> > To: "OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@lists.openstack.org> > Date: 03/18/2016 07:30 AM > Subject: Re: [openstack-dev] [nova] working on bug reports; what blocks you? > > On Thu, Mar 17, 2016 at 03:28:48PM -0500, Matt Riedemann wrote: > > On 3/17/2016 11:41 AM, Markus Zoeller wrote: > > >What are the various reasons which block you to work on bug reports? > > >This question goes especially to the new contributors but also to the > > >rest of us. For me, personally, it's that most bug reports miss the > > >steps to reproduce which allow me to see the issue on my local system > > >before I start to dig into the code. > > > > > >I'm asking this because I'm not sure what the main reasons are that > > >our bug list is this huge (~1000 open bug reports). Maybe you have > > >reasons which can be resolved or mitigated by me in my bug czar role. > > >Let me know. > > Effective bug reporting is top issue for me. By "effective" I mean: > > - Not assuming any prior context while writing a report. (Especially > when writing how to reproduce the problem.) > - Not forgetting to state changes made to various configuration > attributes > - Describing the problem's symptoms in chronological order. > - Describing the test environment precisely. > > Writing a thoughtful report is hard and time-taking. Yeah, and I assume that's the reason many bug reports lack that information. I have the hope to dig deeper into the logging capabilities of Nova during the P cycle, to figure out how much we internally already know but don't offer easily enough. In some bug reports I suggested to use sosreport and attach the file then, but I didn't see that happen. In my head there would be openstack CLI commands like these two: $ openstack report-bug <request-id> $ openstack report-bug --last 10m That should then result in an upstream bug report which answers the usual questions we have. Don't ask me details how this would happen. > https://wiki.openstack.org/wiki/BugFilingRecommendations > > > Clear recreate steps is probably #1, but also logs if there are > > obvious failures. A stacktrace goes a long way with a clear > > description of the failure scenario. Obviously need to know the level > > of code being tested. > > > > For a lot of bugs that are opened on n-2 releases, like kilo at this > > point, my first question is, have you tried this on master to see if > > it's still an issue. That's lazy on my part, but it's easy if I'm not > > aware of a fix that just needs backporting. > > I don't view it as being lazy on your part. Other open source projects > use a similar method -- e.g. in Fedora Project, one month after N+2 > (Fedora-24) is released, 'N' (Fedora-22) goes End-of-Life. And, all > bugs (that are not solved) reported against 'N' (for components with > high bug volume) are closed, with a request to re-test them on N+2 > (latest stable release), and re-open it if the issue persists. > Otherwise, it becomes difficult to cope with volume. In an ideal world with unlimited resources we could do that on our own without asking the reporter, but I guess we should do the "please recheck if it's in master" thing more often. > > -- > /kashyap > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > Regards, Markus Zoeller (markus_z) __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev