How to Report Bugs in LibreOffice

From The Document Foundation Wiki
< QA
Jump to: navigation, search
This page is a translated version of the page QA/BugReport and the translation is 5% complete.

Outdated translations are marked like this.
Other languages:
العربية • ‎Deutsch • ‎Ελληνικά • ‎English • ‎español • ‎français • ‎galego • ‎italiano • ‎日本語 • ‎Nederlands • ‎português do Brasil • ‎русский • ‎Türkçe • ‎中文(中国大陆)‎ • ‎中文(简体)‎ • ‎中文(台灣)‎

Glad you made it here. You are about to make an important contribution to LibreOffice. A good bug report is very helpful for our developers. Below, you'll find some guidance to make this process easier.

Not all bugs go to Bugzilla

All dogs may go to heaven⁠Wikipedia logo v3.svg, but some bug reports should be filed outside of Bugzilla. These include:

Class of Bugs Where to file the bug
LibreOffice Extensions With the extension author
TDF/LibreOffice Infrastructure (websites, mailing lists, etc.) Redmine
Building LibreOffice Developer mailing list
LibreOffice Unit Tests Developer mailing list

在提交 bug 之前,您必须知道

先确认,您发现的问题 确实 是个 bug.

Confirm that it really is a bug. Most of the time, a bug is something that makes the software behave in a way that a reasonable user would not want it to behave. This includes the software not doing what you want it to do, doing what you never asked it to do, or just plain crashing under normal use. Going behind the scenes, a bug may be something that causes the software to take a lot longer and use a lot more resources doing stuff than it should.

如果您确信所发现的问题确实是个 bug, 那么下一步您需要: 1. 做简单的笔记,从而您能够记得 bug 出现时您正在进行什么操作,发生了什么错误情况,正确情况应该是怎么样的?您是怎么知道发生了错误,而不是正确的结果?您能否可靠地重现该 bug? 2. 检查 已有的 bug 报告,看看您遇到的问题别人是否已经上报了

  1. Bugzilla 高级搜索页面:Summary 框输入合适的关键词, Product 选择 LibreOffice,Component 选择 bug 所在部件。其他字段可以留空,也可以根据情况输入,以缩小查询范围。然后点击 Search 按钮进行搜索。进行之前您需要有 bugzilla 的账户并已登录。
  2. 查看搜索结果条目,判断是否有已经报告过的相同或类似的报告。
  3. 如果找到了相同的已经报告过的bug, 您不用再提交新的bug了,直接将自己加入到已报告的bug的cc抄送列表里即可 (Add me to CC list),以便该bug有任何进展时您能随时收到邮件通知。这是因为,QA 团队的人手有限,重复报告 bug 会让有限的精力浪费在没有必要的事情上。

3. 如果没有已报告的bug, 那么进行下一步。

提交 bug

当您发现一个问题,确认是个bug, 在 bugzilla 上也没有找到相同的报告,那么您需要提交新的 bug 报告。请务必确保为每个单独的问题提交单独的报告;在您不确认这是两个问题还是一个问题的情况下,推荐的做法是提交两个不同的 bug 报告。

要提交新的 bug 报告,请进入 TDF官方缺陷跟踪系统,并参考以下步骤:

But let’s say what you found really does look like a bug. Here’s what to do next:

  1. Take notes so you don’t forget something that was going on around the time the bug appeared. What were you doing, what did you expect to happen, and what actually happened? How did you know something was wrong? Can you reproduce the bad behavior?
  2. Check for similar, existing bug reports:
    1. Go to Components, and select the appropriate component (or subcomponent).
    2. If you selected a component: select the appropriate subcomponent, or Extended Help if you don’t see the subcomponent on that page.
    3. If you selected Extended Help: select the appropriate subcomponent, or the [1] at the bottom of the list if you did not find or do not know the appropriate subcomponent.
    4. You will see a list of bugs with that subcomponent. At the bottom of the page, select Edit Search. There, you can modify the search according to your needs.
    5. If you find a bug report that concerns your problem, you can contribute to it. If you don’t find a bug report that concerns your problem, file a new bug report.
  3. If the bug only occurs on Ubuntu or is related to printing, go to #More Information.
  4. After all that, if it does not look like there is a bug report about this issue, follow the instructions at #Submitting a bug.

Submitting a bug

File a separate bug report for each bug you run into, even if the symptoms from a user’s point of view seem identical. Different problems with different roots that appeared in different LibO versions might have to be fixed by different people, for different versions, and at different times. It is impossible to track that in a single bug report.

Go to Bugzilla.

登录,新建 bug 报告

用您的 TDF Bugzilla 账号登陆,然后点击左上方的 New 链接,以打开新建 bug 报告页面。

If you are prompted to sign in, log in with your Bugzilla account.

选择产品

In Component, choose the component.

点击 LibreOffice.

输入 bug 详情

首先,请阅读上方小字部分的说明,尤其是红色加粗的文字,其大意是您提交给 bug 跟踪系统的信息将会被所有人看到,并且无法删除,因此如果您要附加示例文档的话,请务必首先去除保密信息。这一点很重要,否则涉及商业秘密泄露的问题后果会很严重。 Summary:用英文输入该问题的简短描述。描述应当能够反映问题的详细情况,避免模棱两可,避免只说有问题而不说到底有什么问题;尽量包含能反映问题本质的关键词,这样会方便别人搜索时能找到这个问题;对于程序崩溃的问题,Summary 中一定要有 crash 或者 hang 两个词之一,这样才能被更快修复。比如,如果您遇到的问题是在打开打印对话框中的“选项”标签页时程序崩溃,那么您应该写 "Crash if I open the Print dialog and click the 'Options' tab", 而不是 "LibreOffice crashed"。又如,如果您想要提交新功能的建议,那么标题中应当直接描述希望有的功能,而不是只说 "new features" (tdf#114863. Description:用英文详细扩展一下 Summary 中的内容,说明你是如何发现问题的,发现了什么问题。 Component: 选择出现问题的部件。 Hardware:选择您发现该问题时所使用的计算机体系架构,比如是32位(X86)还是64位(X86-64)。 Operating System:选择出现问题时您所用的操作系统。这里需要注意,如果您只是在 Windows 下遇到问题,而根本没有在其他系统比如 Linux 下测试过是否有问题,那么只选 Windows 即可,千万不要选 All, 那样只会让问题变复杂。 Version: 选择出现该问题对应的最老的软件版本。比如,您能重现该问题是在 5.4.4.2 版本中,那么选择 5.4.4.2;如果您能在 5.4.4.2 上重现,同时您也试了一下之前发布的 5.3.1.2 版本也能重现,那么此处应该选择 5.3.1.2. 这个字段永远显示的是最早出现问题的版本,它将用于查找到底是哪个时间哪个代码提交导致该问题的出现,从而更快修复。记住,在您确认别人提交的bug时,不要将该字段改为更新的版本。 Reproducibility:您能否100%重现该bug,还是有时候能重现,有时候又工作正常。 Severity:问题的严重性。一般情况下,都应该是 Normal. 但是对于基本功能严重不正常的bug,你可以提升严重性等级。

Steps to Reproduce:提供重现步骤,即其他人应该怎么操作,才能99.9%重现这个问题。这里一定要用 1,2,3 的数字编号形式列出步骤,而且对步骤的描述一定要足够精确、简洁。这样能方便别人跟着您给出的步骤进行快速测试。 Actual Results:当前的错误结果。这个很重要,因为某个错误在您的机器和软件版本上显示为1,在别人的机器上可能显示为2。 Expected Result: 期望的结果,即正确的情况下应该出现什么结果。千万不要假定其他人知道一切,即便是很简单的问题,您也一定要说到位,因为如果让别人去猜测,那么100个人对同一个问题会有100种不同的理解。 Additional Information: 提供额外的信息。在这里,您必须复制粘贴“帮助 > 关于 LibreOffice”界面中的信息到这个框里,这些信息包含了重要的信息,以利于判断问题。另外,您必须指出您使用的操作系统类型即版本,比如如果您使用Linux系统,那么指出是 Fedora 27 还是Ubuntu 16.04 LTS,是 Gnome 桌面还是 KDE 桌面。如果是 Windows,那么是 Win10 还是 Win7 或者已经不受支持的 WinXP。您可以包含其他您认为必要的信息。 Did you try resetting your UserProfile:您是否尝试过重置过 LibreOffice 的用户配置文件夹。很多情况下,如果出现问题,将用户配置文件夹重置可能问题会消失。对于 LibreOffice 5.3 及更新的版本,您可以通过菜单项“帮助 > 以安全模式重新启动“来测试安全模式下(模拟的全新用户配置)是否存在相同的问题。对于之前的旧版本,你需要手动重命名用于配置文件夹。Windows XP 下,该文件夹位于 "C:\Documents and Settings\<user name>\Application Data“里;在 Win10下,该文件夹可能位于"C:\Users\<user name>\AppData\Roaming"中。 Is OpenGL enabled: 您是否开启了 OpenGL. 默认情况下,如果可能那么 LibreOffice会开启 OpenGL 进行硬件加速。但是,对于某些有bug的显卡,该选项会存在兼容性问题,比如出现界面图标错位、画屏、闪烁等情况。您可以在“工具 > 选项 > LibreOffice > 视图”中查看是否已开启“为所有渲染启用OpenGL"选项。

If it is an urgent issue (broken parts, regression, etc.), and you are an experienced user who knows the development team, you can assign the bug report to one of the developers listed on the FindTheExpert page.

Details

If there is a Sub-component section, select the subcomponent.

If you don’t know the appropriate subcomponent, go to Components. On that page, click on the appropriate component. Read the descriptions of the all the subcomponents on the page of that component. If you don’t see a suitable subcomponent, click on Extended Help, and read the descriptions of the subcomponents on that page.

Choose the version of the application in which the bug appeared. To check what version of LibreOffice you are using, select Help ▸ About LibreOffice

In Operating system or OS, choose the operating system of the computer you were using when you met the bug.

If there is a Hardware section, fill it in.

If there is a Severity section, ignore it unless you are experienced. Selecting Blocker will not get the bug fixed faster. If you want to know the definitions of the items in the Severity section, see this chart.

You can ignore the section latest known-working version.

Subject

Check in possibly related Bugs table on the bug-reporting page and additionally in the Duplicates Table to see whether the problem really has not been reported yet.

In the Subject section (also known as the Summary):

  • Do not include information already known from the fields.
  • Include the names of subcomponents from Components.
    • Make the subcomponents uppercase.
    • If the subcomponent can be confused with parts of a word (for example, UI is part of the word quit), surround the subcomponent with square brackets.
    • Use at most two subcomponents.
    • Use subcomponents exactly as they appear in the list, but you may integrate them into the subject line sentence like “WIKIHELP [UI] not available in all languages”.
  • Summarize the problem fairly precisely.
    • bad example: “File is broken”
    • better example: “Menu File > Save as not available (greyed out)”
  • Avoid short forms like “doesn’t” or “isn’t” to ease queries for strings in the Summary; instead, use the full form, such as “does not” or “is not”.
  • If the problem written in the report is that LibreOffice crashes or stops responding (“hangs”), add the word CRASH to the Summary, so that these bugs can be located and tracked easily.

Description and attachments

In the Long Description or Description section, give a lengthier, factual description of the problem:

  • list the steps to reproduce the bug;
  • use a numbered list; and
  • state the exact method to make something happen. For example, instead of writing “Open document”, write instead “In new empty LibO Spreadsheet document, use menu File > Open (LibO dialog) > file type “Text documents” > select attached sample document > double click”.

If you’re using a pre-built LibreOffice on Linux, list the exact versions of LibreOffice packages in your package management system. If you’re using Windows, list the exact filename of the installer, and from where it was downloaded.

  • Including information about installed and used localization (UI language, document language) might be useful.
  • Include whether a 32-bit LibreOffice is used on a 64-bit (Linux) system.
  • Include the package source if it’s not the official LibreOffice build.

Write the expected behavior and the actual behavior.

You can include an attachment, such as a screenshot or a sample document. The typical way to take a screenshot is to press the "Print Screen/PrtScn" button on your keyboard. Depending on your operating system, you might have to then open an image editing application (such as Paint on Windows) and do Edit - Paste in it.

  • If you create screenshots, switch the language to English before making the screenshot. You can do so in Tools ▸ Options ▸ Language Settings ▸ Languages.
  • You can make screenshots more useful by adding comments and marking relevant areas with LibreOffice Draw.
  • If you want to attach more than one screenshot, you should collect them all in one document (copy / paste to a LibreOffice Draw document) and attach as a PDF. Please add a short comment to each screenshot to tell what you want to demonstrate with it.
  • If you attach a sample document that exhibits the bug you are reporting, please make the document as minimal as possible. For example, for Writer bugs, the document should ideally have just a single paragraph. To make it easy to find the text from your document in debug tracing, use some very easily recognizable text, like AAAAAAAAAA ₂ ZZZZZZZZZZ for a bug that is triggered by that character.
  • It is preferable to upload attachments individually. However, if you want to attach more than half a dozen documents, create a .zip file containing all documents and attach that .zip.
  • If your attachment is too big to be attached in Bugzilla (bigger than 1 MB) you can use the Experimental upload page.

Status

The only time you should change the status to NEW is, if someone already confirmed the bug elsewhere (Ask, mailing list, some forum). In these cases, provide a link to the discussion with the confirmation.

Submit Bug Report: 检查上列信息已完整无误,然后单击这个按钮以提交 Bug. Add an Attachment:如果您需要添加附件,比如一个截图或者一个示例文档,那么需要在点击上述的 Submit Bug Report 按钮创建了bug之后,再点击 Add an Attachment 链接添加。很多时候,说一大堆的话,还不如添加一个截图说的清楚,尤其是当您英文“不咋滴”的时候。

Click Submit, and your report will be added to the Bugzilla database.

如果您感觉在 Bugzilla 上提交 bug 太困难

提交 bug 的首选途径是 TDF 的官方 Bugzilla。但是,如果您实在不想在那里提交,那么:

If the Bugzilla bug tracking system seems daunting or too hard to understand, you should post your problem here:

Even if you post your problem on those channels, your goal should be to get a good bug report on bugzilla. These channels might help you with that. Note, that reporting problems on social media (Facebook, Twitter etc.) is not productive in general as it will rarely lead to a good bug report ending up in bugzilla (see also: 99 ways to ruin an open source project, top 5).

提交了 bug 之后

如果您提交的bug在过了很久之后仍然无人问津(例如,对于严重的bug在过了24小时之后,或者对于功能改进建议提交了14天之后),那么请考虑主动联系其他人让其尝试重现您报告的bug,比如通过 users@global.libreoffice.org 邮件列表 或者 IRC 频道 #libreoffice connect via webchat,或者 由 LibreOffice 中文社区

If nobody has reviewed your report within an appropriate time (24 hours for a critical bug, 14 days for an enhancement request), consider asking someone else to reproduce your bug report on the users@global.libreoffice.org mailing list or IRC channel #libreoffice connect via webchat.

向提交的 bug 中添加评论

  • 避免使用 "me too" 这样的没有任何意义的评论。任何评论在提交之前都要确保其能提供更加有价值的信息,否则就等于给大家制造麻烦,因为一个bug报告里的杂乱信息太多时,开发者可能根本就没有耐心看下去了。但是,例外情况是,对于尚处于UNCONFIRMED状态的bug,您可以提交评论说明您也能重现该bug,并指出您的重现步骤、软件版本、操作系统等额外信息,然后将bug标记为NEW.
  • 避免发布例如“我们公司有1000台电脑想要安装LibreOffice,唯有这个bug导致我们没法迁移”这样的评论,这样的评论对于bug修复本身没有任何意义,只能使得bug报告更加杂乱,没有头绪。您可以在社区论坛里发布这样的抱怨,或者IRC聊天频道里,或者您的个人博客上,或者社交媒体上,都没有问题。
  • Avoid posting “me too” comments which contain no additionally useful information.
    The exception to this is when you comment on a bug that has been UNCONFIRMED so far. In that case, please provide reproduction steps (or confirm the ones given by the original reporter) and move the issue to status NEW. Note that if there are no clear reproduction steps, the issue might quickly move back to NEEDINFO, so finding a good and simple reproduction scenario is essential.
  • Refrain from adding comments along the line of “we have 1000 seats here and only this bug prevents us from migrating”, as it contains no additional information relevant to QA or to the priority of the issue.

LibreOffice is open source and your help in fixing issues that are relevant to your particular situation is most welcome. You can:

  • Employ and/or teach your own developers to work on LibreOffice. We are most happy to mentor them: see the developer’s pages.
  • Fund individuals or companies to work on specific issues - see the list of certified developers.
  • Contact The Document Foundation to help you if you have only a small amount of funding, and want to collaborate, coordinate or pool your resources with others in the same situation to fund specific fixes or enhancements.

好的 bug 报告

好的bug报告更容易在最短的时间内被修复。其至少需要包含以下信息:

  1. 操作系统及 LibreOffice 的版本号;
  2. 以数字列表形式列出的清晰的重现步骤;
  3. 尽可能简单的 示例文档,用于定位问题;
  4. 包含有期望的结果。

Minimum requirements

  1. OS/LibreOffice version;
  2. enumerated reproducible steps;
  3. simple attachments where appropriate; and
  4. observed/expected results.

以下是一些好的 bug 报告的范例:

  • tdf#85004 - Writer: Crash when clicking the Reminder icon on the Navigation toolbar
  • tdf#87907 - DIALOG: Page preview in print dialog refreshes when opening print details
  • tdf#74839 - EDITING: Position of connectors connected to a group aren't updated when editing group content
  • tdf#85004 - Writer: Crash when clicking the Reminder icon on the Navigation toolbar
  • tdf#87907 - DIALOG: Page preview in print dialog refreshes when opening print details
  • tdf#74839 - EDITING: Position of connectors connected to a group aren't updated when editing group content

不好的 bug 报告

  • 大段的文字描述,说了半天没有说出重点,令人头晕眼花。
  • 一个报告里包含5个不同的问题。这5个问题可能的确是相关的,但是从代码的角度来说它们可能属于不同的问题,需要不同的patch去修复。此时,您应该将这5个问题拆分为5个小问题,这样会使问题变得简单,更容易被分别修复。

Reports can be less than ideal for a number of reasons. Below are some of the common problems:

  • 缺少细节和重新步骤。有些人报告bug,只说有问题,不正常,或者不能工作,而丝毫不说到底哪里有问题,哪里不正常,什么地方不能正常工作,也不说按照什么步骤操作才能发现所说的问题。
  • 夹杂/添加不相关的信息。这样的不相关的信息只会让bug报告变得臃肿,让别人失去兴趣。例如:有些人会描述说”这是个非常严重的bug“,然后列出一系列的理由指出它为什么是个非常严重的bug,或者说由于这个bug我无法使用LibreOffice了,或者得出结论说”LibreOffice真垃圾“,或者”在这个

Describing a bug report in paragraphs of text is one of the most common problems. Developers do not have the time to read paragraphs of text. Clear, succinct, enumerated steps are always better.

One Report, Five Bugs

One report should only have a single bug in it. Grouping bugs, or listing a whole list of issues with a single document, is utterly unhelpful. In order to find developers to tackle issues, it is best to give them a single issue to focus on. They are unlikely to take on a bug that has multiple issues listed

Missing Details/Steps

All bug reports should have at minimum:

  1. your Operating System and version of LibreOffice;
  2. clear reproducible steps;
  3. expected results;
  4. observed results; and
  5. a simple attachment where appropriate.

Adding Superfluous Information

Adding a lot of extra details that aren’t relevant is another common problem. Examples include:

  1. “this is a blocker”;
  2. a long list of reasons why it’s a blocker;
  3. “I can’t use LibreOffice because of this bug”;
  4. “LibreOffice sucks” (or any variation of that); and
  5. I’m going to start using your competitor unless you fix it.

Complex Attachments

Attachments should be as simple as possible. Take the time to prune your examples to the bare minimum. This helps tremendously in diagnosing problems.

bug没有修复之前我将使用其他Office软件“,等等。

  • 上传复杂的附件。上传的示例文档一定要尽可能简单,这样才能更快定位问题。
  • 假定其他人知道一切。

Do not assume contributors know what you’re talking about. Describe your steps clearly, each step of the way.

更多信息