Open Stack

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 [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?

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.

Best regards,

Fahri Cihan Demirci

> 
> References:
> [1] Nova core reviewers list:
>     https://review.openstack.org/#/admin/groups/25,members
> 
> Regards, Markus Zoeller (markus_z)
> 
> 
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev