Re: [openstack-dev] [nova] bug discussion at mid cycle meet up
On Tue, Jul 29, 2014 at 02:48:12PM -0400, Russell Bryant wrote: On 07/29/2014 11:43 AM, Tracy Jones wrote: 3. We have bugs that are really not bugs but features, or performance issues. They really should be a BP not a bug, but we don’t want these things to fall off the radar so they are bugs… But we don’t really know what to do with them. Should they be closed? Should they have a different category – like feature request?? Perhaps they should just be wish list?? I don't think blueprint are appropriate for tracking requests. They should only be created when someone is proposing actually doing the work. Agreed, we really do not want to see blueprints created for people who are just doing 'drive by' feature requests. I think Wishlist is fine for keeping a list of requests. That's what I've been using it for. Yep, wishlist works fine IMHO - it is a nice low overhead approach for users wanting to report these kind of items, with a tool they are already familiar with. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova] bug discussion at mid cycle meet up
At the mid-cycle meet-up yesterday we spent some time looking at our bug dashboard (http://54.201.139.117/nova-bugs.html) and talking about things we can do to help focus on bugs. We came up with the following ideas. I’d like folks to weigh in on these i if you have some ideas or concerns. 1. Start auto-abandoning bugs that have not been touched (I.e. Updated) in the last 60 days.We would have something (a bot?) that would look at bugs that have not been updated (nor their review updated) in the last 60 days. The bug would be set to the “new” state and the assignee would be removed. This would cause the bug to be re-triaged and would be up for someone else to pick up. 2. Also - when a bug has all abandoned reviews, we should automatically set the bug to new and remove the assignee. 3. We have bugs that are really not bugs but features, or performance issues. They really should be a BP not a bug, but we don’t want these things to fall off the radar so they are bugs… But we don’t really know what to do with them. Should they be closed? Should they have a different category – like feature request?? Perhaps they should just be wish list?? 4. We should have more frequent and focused bug days. For example every Monday have a bug day where we focus on 1 area (like api or compute or networking for example) and work on moving new bugs to configured, or confirmed bugs to triaged. I’ll talk with Michael about when to schedule the 1st “focused” bug day and what area to address. In generate we need to tighten up the definition of triaged and confirmed. Bugs should move from New - Confirmed - Triaged - In Progress. JayPipes has updated the wiki to clarify this. * Confirmed means someone has looked at the bug, saw there was enough into to start to diagnose, and agreed it sounds like a bug. * Triaged means someone has analyzed the bug and can propose a solution (not necessarily a patch). If the person is not going to fix it, they should update the bug with the proposal and move the bug into Triaged. If we do implement 1 and 2 I’m hoping the infra team can help – I think dims volunteered ;-) I made a note to add review stats to the bug page to make it easier to see how far along a bug is in review ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] bug discussion at mid cycle meet up
On 07/29/2014 11:43 AM, Tracy Jones wrote: 3. We have bugs that are really not bugs but features, or performance issues. They really should be a BP not a bug, but we don’t want these things to fall off the radar so they are bugs… But we don’t really know what to do with them. Should they be closed? Should they have a different category – like feature request?? Perhaps they should just be wish list?? I don't think blueprint are appropriate for tracking requests. They should only be created when someone is proposing actually doing the work. I think Wishlist is fine for keeping a list of requests. That's what I've been using it for. In generate we need to tighten up the definition of triaged and confirmed. Bugs should move from New - Confirmed - Triaged - In Progress. JayPipes has updated the wiki to clarify this. * Confirmed means someone has looked at the bug, saw there was enough into to start to diagnose, and agreed it sounds like a bug. * Triaged means someone has analyzed the bug and can propose a solution (not necessarily a patch). If the person is not going to fix it, they should update the bug with the proposal and move the bug into Triaged. We should be careful not to conflict with the guidelines set for all OpenStack projects here: https://wiki.openstack.org/wiki/BugTriage For example, that page says when a bug should be set to Confirmed or Triaged. In most cases, it's Confirmed. Triage is when there is a known solution. -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] bug discussion at mid cycle meet up
On 07/29/2014 11:48 AM, Russell Bryant wrote: On 07/29/2014 11:43 AM, Tracy Jones wrote: 3. We have bugs that are really not bugs but features, or performance issues. They really should be a BP not a bug, but we don’t want these things to fall off the radar so they are bugs… But we don’t really know what to do with them. Should they be closed? Should they have a different category – like feature request?? Perhaps they should just be wish list?? I don't think blueprint are appropriate for tracking requests. They should only be created when someone is proposing actually doing the work. I think Wishlist is fine for keeping a list of requests. That's what I've been using it for. There's a metric crap-ton of bugs that are *not* in Wishlist and are instead in High or Medium importance, but they are not necessarily bugs that either have a specific solution -- see: performance-related bugs -- or are things that frankly can never be fixed. We don't want to keep these things as bugs, because they aren't really bugs, but the blueprint/spec stuff isn't appropriate for epics that are like super-specs to be used to track general themes. We think that a separate category of thing is needed for tracking these themes. In Agile, these things are called epics. In generate we need to tighten up the definition of triaged and confirmed. Bugs should move from New - Confirmed - Triaged - In Progress. JayPipes has updated the wiki to clarify this. * Confirmed means someone has looked at the bug, saw there was enough into to start to diagnose, and agreed it sounds like a bug. * Triaged means someone has analyzed the bug and can propose a solution (not necessarily a patch). If the person is not going to fix it, they should update the bug with the proposal and move the bug into Triaged. We should be careful not to conflict with the guidelines set for all OpenStack projects here: https://wiki.openstack.org/wiki/BugTriage For example, that page says when a bug should be set to Confirmed or Triaged. In most cases, it's Confirmed. Triage is when there is a known solution. So, yeah, we went back and forth on this. One thing that was mentioned is that by setting something to Wishlist from, say, High, we downplay the importance of the particular bug, which, for performance and scalability epics tends to annoy both the bug submitter and the bug owner. However, setting the bug to New, which triggers a re-verification and/or re-triaging of the issue, puts the onus and responsibility on the bug triaging team and allows the bug to be taken off of the In progress but Abandoned list and not lost into the general swamp of In progress but not assigned. Anyway, just food for thought. -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
