From b137942ea71e8868dff2cbc75b3b17ed8cdc48b5 Mon Sep 17 00:00:00 2001 From: Akos Kiss Date: Tue, 2 Jul 2019 16:12:40 +0200 Subject: [PATCH] Add issue template for bug reports (#2940) Help both the community and ourselves by describing what information is required in a bug report. JerryScript-DCO-1.0-Signed-off-by: Akos Kiss akiss@inf.u-szeged.hu --- .github/ISSUE_TEMPLATE/bug_report.md | 77 ++++++++++++++++++++++++++++ 1 file changed, 77 insertions(+) create mode 100644 .github/ISSUE_TEMPLATE/bug_report.md diff --git a/.github/ISSUE_TEMPLATE/bug_report.md b/.github/ISSUE_TEMPLATE/bug_report.md new file mode 100644 index 000000000..569c9435b --- /dev/null +++ b/.github/ISSUE_TEMPLATE/bug_report.md @@ -0,0 +1,77 @@ +--- +name: Bug report +about: Create a report to help us improve + +--- + +First of all, when reporting a bug, give the issue a descriptive title. + +In the body of the issue, optionally give a free-form text description of the +bug. Give the context necessary for others to understand the problem. + +Then, provide information necessary to reproduce the bug. +Omit sections that are irrelevant for the bug report, but note that information +like git revision, build platform, build command, and test case are required in +almost all cases. + +###### JerryScript revision +Identify the git hash(es) or tag(s) where the issue was observed. + +###### Build platform +Name the build platform. E.g., copy the output of +`echo "$(lsb_release -ds) ($(uname -mrs))"` (on Linux), +`echo "$(sw_vers -productName) $(sw_vers -productVersion) ($(uname -mrs))"` (on macOS), or +`python -c "import platform; print(platform.platform())"` (should work everywhere). + +###### Build steps +Describe how to build JerryScript. Give all the necessary details of the build +(e.g., environment variables, command(s), profile, command line options, etc.). + +E.g.: +```sh +tools/build.py --clean --debug +``` +Or: +```sh +mkdir build && cmake -H. -Bbuild && make -C build +``` + +Even if the bug was originally observed when JerryScript was integrated into a +larger project, try to reproduce it with as few external code as possible, +preferably by building the `jerry` command line tool. + +###### Build log +Copy the build log if the reported issue is a build problem. Do a verbose build +if necessary. Try and trim the log to relevant parts. + +###### Test case +Give the JavaScript input that should be passed to the engine to trigger the +bug. Try and post a reduced test case that is minimally necessary to reproduce +the issue. As a rule of thumb, use Markdown's fenced code block syntax for the +test case. Attach the file (renamed to .txt) if the test case contains +'problematic' bytes that cannot be copied in the bug report directly. + +###### Execution platform +Unnecessary if the same as the build platform. + +###### Execution steps +List the steps that trigger the bug. + +E.g., if a bug is snapshot-specific: +```sh +build/bin/jerry-snapshot generate -o testcase.js.snapshot testcase.js +build/bin/jerry --exec-snapshot testcase.js.snapshot +``` + +Unnecessary if trivial (i.e., `build/bin/jerry testcase.js`). + +###### Output +Copy relevant output from the standard output and/or error channels. + +###### Backtrace +In case of a crash (assertion failure, etc.), try to copy the backtrace from a +debugger at the point of failure. + +###### Expected behavior +Describe what should happen instead of current behavior. Unnecessary if trivial +(e.g., in case of a crash, the trivial expected behavior is not to crash).