Re: [openstack-dev] [QA] Proposal: A launchpad bug description template
Markus Zoeller wrote: TL;DR: A proposal for a template for launchpad bug entries which asks for the minimal needed data to work on a bug. Note that Launchpad doesn't support bug entry templates. You can display bug reporting guidelines which appear under the textbox, but that's about it. Also note that the text is project-specific, so it needs to be entered in every openstack project. Depending on the exact nature of the project, I suspect the text should be different. Regards, -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [QA] Proposal: A launchpad bug description template
Thierry Carrez thie...@openstack.org wrote on 10/17/2014 11:28:56 AM: From: Thierry Carrez thie...@openstack.org To: openstack-dev@lists.openstack.org Date: 10/17/2014 11:31 AM Subject: Re: [openstack-dev] [QA] Proposal: A launchpad bug description template Markus Zoeller wrote: TL;DR: A proposal for a template for launchpad bug entries which asks for the minimal needed data to work on a bug. Note that Launchpad doesn't support bug entry templates. You can display bug reporting guidelines which appear under the textbox, but that's about it. Also note that the text is project-specific, so it needs to be entered in every openstack project. Depending on the exact nature of the project, I suspect the text should be different. Regards, -- Thierry Carrez (ttx) Thanks for the note on Launchpads capabilities. Providing the infor- mation in the bug reporting guidelines on launchpad looks like a good place. Currently there is for Nova Please include the exact version of Nova with which you're experiencing this issue.. The wiki page about the bugs [1] could be enhanced as well and then we could let Launchpad link to this wiki page. Maybe this would reduce the maintenance of the template. Subsections could be introduced for project specific debug data. [1] https://wiki.openstack.org/wiki/Bugs Regards, Markus Zoeller IRC: markus_z ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [QA] Proposal: A launchpad bug description template
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 - ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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 mzoel...@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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [QA] Proposal: A launchpad bug description template
Masayuki Igawa masayuki.ig...@gmail.com wrote on 10/16/2014 03:41:24 PM: From: Masayuki Igawa masayuki.ig...@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@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 mzoel...@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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
