Open Stack

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 [1]).

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
  solutions.
* 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?

References:
[1] Nova core reviewers list:
    https://review.openstack.org/#/admin/groups/25,members

Regards, Markus Zoeller (markus_z)