Open Stack

First off, thank you so much for starting this effort Jason! Responses inline:

On Tue, Feb 5, 2019 at 12:37 PM Jason Grosso <jgrosso at redhat.com> wrote:
> 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?

IMHO, we could start doing these biweekly with a synchronized meeting.
I feel once we bring down the number of bugs to a manageable
number, we can go back to using our IRC meeting slot to triage new
bugs as they come and gather progress on existing bugs.

> 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?

If a fix has been committed, an appropriate Gerrit review patch should
be noted, unless our automation fails (which happens sometimes)

> 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?

This has been informal so far, and our bug supervisors group
(https://launchpad.net/~manila-bug-supervisors) on Launchpad is a
small subset of our contributors and maintainers; if a bug causes a
security issue, or data loss it is marked CRITICAL and scheduled to be
fixed right away. If a bug affects manila's API and core internals, it
is marked between HIGH and LOW depending on whether we can live with a
bug not being fixed right away. Typically vendor driver bugs are
marked LOW unless the driver is badly broken.

We usually reduce the bug importance if it is HIGH, but goes un-fixed
for a long time. We don't have stats around turnaround time, gathering
those would be an interesting exercise.

> 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?

Great point, it feels like we shouldn't. If we start triaging new bugs
as they come, they should not be "NEW" for too long.

> 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.

Great stuff :) The sheet [1] requires permissions, so your thought of
using ethercalc.openstack.org [3] may be the way to go! We can start
referring to this in our meetings.

> [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