Open Stack

Masayuki Igawa <masayuki.igawa at gmail.com> wrote on 10/16/2014 03:41:24 PM:

> From: Masayuki Igawa <masayuki.igawa at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)" 
> <openstack-dev at lists.openstack.org>
> Date: 10/16/2014 03:44 PM
> Subject: Re: [openstack-dev] [QA] Proposal: A launchpad bug 
> description template
> 
> Hi Markus,
> 
> Thank you for bringing up this.
> 
> On Thu, Oct 16, 2014 at 9:13 PM, Markus Zoeller <mzoeller at de.ibm.com> 
wrote:
> > TL;DR: A proposal for a template for launchpad bug entries which asks
> >        for the minimal needed data to work on a bug.
> >
> >
> > Hi,
> >
> > As a new guy in OpenStack I find myself often in the situation that 
I'm
> > not able to work on a bug because I don't understand the problem 
itself.
> > If I don't understand the problem I'm not able to locate the source of
> > the issue and to provide an appropriate patch.
> >
> > As the new guy I don't want to flood the bug entry with questions what
> > it should do which might be obvious to other members. And so, wrt
> > Igawas comment in the mail thread "[openstack-dev] [qa] Tempest Bug
> > triage" (http://openstack.markmail.org/thread/jcwgdcjxylqw2vyk) I'd
> > like to propose a template for bug entries in launchpad (see below).
> >
> > Even if I'm not able to solve a bug due to the lack of knowledge,
> > reading the bug description written according to this template could
> > help me build up knowledge in this area.
> >
> > Maybe this or a similar template can be preloaded into the description
> > panel of launchpad when creating a bug entry.
> >
> > What are your thoughts about this?
> >
> > Regards,
> > Markus Zoeller
> > IRC: markus_z
> >
> >
> > -------------------------- template start 
-----------------------------
> >
> > Problem description:
> > ======================
> > # Summarize the issue in as few words as possible and as much words as
> > # necessary. A reader should have the chance to decide if this is in 
his
> > # expertise without reading the following sections.
> >
> > Steps to reproduce:
> > ======================
> > # Explain where you start and under which conditions.
> > # List every input you gave and every action you made.
> >
> > # E.g.:
> > # Prereqs: Installed devstack on x86 machine with icehouse release
> > # 1) In Horizon, launch an instance with name "test" an flavor 
"m1.tiny"
> > #    from image "cirros-0.3.1-x86_64-uec"
> > # 2) Launch 2 other instances with different names but with the same
> > #    flavor and image.
> >
> > Expected behavior:
> > ======================
> > # Describe what you thought what should happen. If applicable provide
> > # sources (e.g. wiki pages, manuals or similar) why to expected this.
> > # E.g.:
> > # Each instance should be launched successfully.
> >
> > Observed behavior:
> > ======================
> > # Describe the observed behavior and how it differs from the expected
> > # one. List the error messages you get. Link to debug data.
> > # E.g.:
> > # The third instance was not launched. It went to an error state. The
> > # error message was "host not found".
> >
> > Reproducibility:
> > ======================
> > # How often will the "steps to reproduce" result in the described
> > # observed behavior?
> > # This could give a hint if the bug is related to race conditions
> > # Try to give a good estimate.
> > # E.g. "4/5" (read "four times out of five tries")
> > # 5/5
> >
> > Environment:
> > ======================
> > # Which version/branch did you use?
> > # Details of the machine?
> >
> > Additional data:
> > ======================
> > # Links to http://paste.openstack.org/ with content of log files.
> > # Links to possible related bugs.
> > # Things which might be helpful to debug this but doesn't fit into the
> > # other sections.
> >
> > -------------------------- template end  -----------------------------
> 
> +1!
> 
> I think many of bug descriptions don't have enough information for
> debugging now.  So we should have enough information like this as
> possible.
> However, one thing I'm concerned about this template is a little heavy
> process for submitting an easy bug. We might have some templates for
> depending on the situation.
> 
> Thanks,
> -- 
> Masayuki Igawa
> 

I'm not quite sure if it would be good to omit a proper bug description
even if the author of the bug considers this an "easy" bug. If it is
an easy one it could be tagged with the "low-hanging-fruit" tag and 
left for a new contributor. Sure, it is easier for the *author* to make
a quick description in a bug entry but I assume that this time saving
has to be paid in the later steps of the lifecycle of the bug. 
A bug seems easy to an author because he has already the knowledge to
debug this. Another person will not profit from a short description 
and will not increase his knowledge and help in other (more complicated)
bugs. If a section is irrelevant for this bug (e.g. Environment), than
a short "N/A" could save time for author and reader.

Regards,
Markus Zoeller
IRC: markus_z