Open Stack

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 at redhat.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190205/e22dade3/attachment-0001.html>