Open Stack

Fahri Cihan Demirci <cihand at skyatlas.com> wrote on 01/12/2016 09:58:10 AM:

> From: Fahri Cihan Demirci <cihand at skyatlas.com>
> To: "OpenStack Development Mailing List (not for usage questions)" 
> <openstack-dev at lists.openstack.org>
> Date: 01/12/2016 10:01 AM
> Subject: Re: [openstack-dev] [nova][bugs] help needed: volunteers for 
> bug skimming (1 week)
> 
> 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.

Nova is too complex to specify a new feature in a few sentences in
a bug report. I tend to close those as "invalid" with links to the
blueprint process. The (WIP) proposal [1]  I have pushed today also
wants to omit the usage of the "wishlist" prio but there is not yet
concensus about it.

[1] https://review.openstack.org/#/c/266453/

Regards, Markus Zoeller (markus_z)

> Best regards,
> 
> Fahri Cihan Demirci
> 
> > 
> > References:
> > [1] Nova core reviewers list:
> >     https://review.openstack.org/#/admin/groups/25,members
> > 
> > Regards, Markus Zoeller (markus_z)