Open Stack

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