Fahri Cihan Demirci <cih...@skyatlas.com> wrote on 01/12/2016 09:58:10 AM:
> From: Fahri Cihan Demirci <cih...@skyatlas.com> > To: "OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@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 <aragw...@pobox.com> wrote on 01/08/2016 07:50:23 PM: > > > > > From: Augustina Ragwitz <aragw...@pobox.com> > > > To: "OpenStack Development Mailing List (not for usage questions)" > > > <openstack-dev@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) __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev