Hello All,


This is an email to the OpenStack manila upstream community but anyone can chime in would be great to get some input from other projects and how they organize their upstream defects and what tools they use...



 My goal here is to make the upstream manila bug process easier, cleaner, and more effective.


My thoughts to accomplish this are by establishing a process that we can all agree upon.



  I have the following points/questions that I wanted to address to help create a more effective process:

  

  • Can we as a group go through some of the manila bugs so we can drive the visible bug count down?

  • How often as a group do you have bug scrubs?

  • Might be beneficial if we had bug scrubs every few months possibly?

  • It might be a good idea to go through the current upstream bugs and weed out one that can be closed or invalid.


  • When a new bug is logged how to we normally process this bug

  • How do we handle the importance?

  • When a manila bugs comes into launchpad I am assuming one of the people on this email will set the importance?

  • "Assigned" I will also assume it just picked by the person on this email list.

  • I am seeing some bugs "fixed committed" with no assignment. How do we know who was working on it?

  • What is the criteria for setting the importance. Do we have a standard understanding of what is CRITICAL or HIGH?

  • If there is a critical or high bug what is the response turn-around? Days or weeks?

  • I see some defect with HIGH that have not been assigned or looked at in a year?

  • I understand OpenStack has some long releases but how long do we normally keep defects around?

  • Do we have a way to archive bugs that are not looked at? I was told we can possibly set the status of a defect to  “Invalid” or “Opinion” or “Won’t Fix” or “Expired"

  • Status needs to be something other than "NEW" after the first week

  • How can we have a defect over a year that is NEW?

  • Who is possible for see if there is enough information and if the bug is invalid or incomplete and if incomplete ask for relevant information. Do we randomly look at the list daily , weekly, or monthly to see if new info is needed?




I started to create a google sheet [1] to see if it is easier to track some of the defect vs the manila-triage pad[2] . I have added both links here. I know a lot will not have access to this page I am working on transitioning to OpenStack ether cal.


[1] https://docs.google.com/spreadsheets/d/1oaXEgo_BEkY2KleISN3M58waqw9U5W7xTR_O1jQmQ74/edit#gid=758082340

[2] https://etherpad.openstack.org/p/manila-bug-triage-pad  

[3] https://ethercalc.openstack.org/uc8b4567fpf4




I would also like to hear from all of you on what your issues are with the current process for upstream manila bugs using launchpad. I have not had the time to look at storyboard https://storyboard.openstack.org/ but I have heard that the OpenStack community is pushing toward using Storyboard, so I will be looking at that shortly.


Any input would be greatly appreciated...


Thanks All,

Jason Grosso

Senior Quality Engineer -  Cloud

Red Hat OpenStack Manila

jgrosso@redhat.com