On Mon, Jan 11, 2016 at 11:21:29AM +0100, Markus Zoeller wrote: > Augustina Ragwitz <[email protected]> wrote on 01/08/2016 07:50:23 PM: > > > From: Augustina Ragwitz <[email protected]> > > To: "OpenStack Development Mailing List (not for usage questions)" > > <[email protected]> > > 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: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
