[openstack-dev] [nova][bugs] help needed: volunteers for bug skimming (1 week)
Fahri Cihan Demirci
cihand at skyatlas.com
Tue Jan 12 08:58:10 UTC 2016
On Mon, Jan 11, 2016 at 11:21:29AM +0100, Markus Zoeller wrote:
> Augustina Ragwitz <aragwitz at pobox.com> wrote on 01/08/2016 07:50:23 PM:
> > From: Augustina Ragwitz <aragwitz at pobox.com>
> > To: "OpenStack Development Mailing List (not for usage questions)"
> > <openstack-dev at lists.openstack.org>
> > Date: 01/08/2016 08:00 PM
> > Subject: Re: [openstack-dev] [nova][bugs] help needed: volunteers for
> > bug skimming (1 week)
> > I signed up for the week before the Nova Midcycle meeting. Even though
> > I'm still new, I feel capable of at least getting the tags mostly right.
> > When I'm not quite sure which tag it would fall under, I search for
> > similar bugs and see how they were tagged.
> Thanks for signing up!
> That's a valid approach.
> > I did have one clarifying question, what exactly are the expectations of
> > the bug skimming duty? I assumed it was just tagging bugs to get them
> > into the appropriate queues for triaging. Do we also need to confirm the
> > bugs once they've been tagged or does that fall under "triage" and not
> > "skimming"?
> > Thanks!
> > Augustina
> In short, do as much as possible before the expertise of the subteams
> is needed. Also, if you spot potential critical bugs, shout out in the
> #openstack-nova channel (for me or one of the core reviewers ).
> As a longer clarification, the duty includes:
> * Switch the bug to "incomplete" when crucial information is missing
> and ask the reporter to provide more information. This includes:
> * steps to reproduce
> * the version of Nova and the novaclient (or os-client)
> * logs (on debug level)
> * environment details depending on the bug
> * libvirt/kvm versions, VMWare version, ...
> * storage type (ceph, LVM, GPFS, ...)
> * network type (nova-network or neutron)
> I subscribe myself to bugs when I switch them to "incomplete" to see
> when responses come in. See "You are not directly subscribed to this
> bug's notifications." on the right hand side of a Launchpad bug report.
> * Close as "invalid" if it is a support request or feature request.
> * Switch to "confirm" if you could reproduce the described issue. This
> is not always possible for you because of missing resources like a
> ceph storage or something like that.
> * Add a tag (or more tags) if the report allows you to narrow down the
> area which potentially contains the issue. This should be the entry
> point for subteams to dig deeper to find the root cause and potential
> * Bring critical bugs to the attention of the other contributors. The
> #openstack-nova channel and/or a ML post is useful.
> I usually explained in a comment *why* I changed a status and which
> next steps I expect from whom. For example, if I switch to "incomplete",
> tell the reporter to add this and that piece of information and to switch
> the bug back to "new" when the reporter has done this. Another example,
> if it was a feature request, I switched to "invalid" and added the links
> to the blueprint process.
> I used the term "skimming" because each day there are new bugs where
> nobody took a look at. They "float" on top of all the other bug reports
> which should have been looked at before.
> I see the whole process in 3 levels:
> * level 1: bug skimming duty => keep the input sane, prepares the
> report for level 2
> * level 2: subteam digs deeper, finds the issue, proposes solution
> ideas for level 3
> * level 3: contributor provides a change in gerrit based on level 2
> Does this clarify some of the open questions?
Thank you for these guidelines. Regarding reports which may be considered as feature requests; there are some reports which were in that vein and were marked with 'Wishlist' importance. Therefore I assumed that classifying feature requests as wishlist items was a valid approach. Was that wrong? Should marking those types of reports as 'Invalid' be the way to go? Thank you.
Fahri Cihan Demirci
>  Nova core reviewers list:
> Regards, Markus Zoeller (markus_z)
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev