Bug 的提交和处理

Bug 跟踪

如:ref:`community_platform`章节所述，OpenERP用Launchpad来作bug管理平台。

任何人都可以自由的报告新的错误(bugs)或是对已存在的错误(bugs)给予反馈在OpenERP的Launchpad软件缺陷追踪系统(bugtracker).唯一的必要条件就是注册一个Launchpad帐号 [https://login.launchpad.net/+new\_account](https://login.launchpad.net/+new_account)\`_并且加入OpenERP社区 [https://launchpad.net/~openerp-community/+join](https://launchpad.net/~openerp-community/+join)\`_ team,仅仅需要几次点击就可以完成.

注解

一些额外的团队成员会被要求完成一些特定的任务,在 Bug 的处理 下节解释.

任何您关注的OpenERP问题会被报告到LaunchPad中适当的项目。一个新问题报告的链接能被发现在每个Launchpad项目的主页右面顶部.这里有一个包含所有OpenERP项目问题的快速概览的链接:

重要

当您尝试汇报一个新的错误,LauchPad错误跟踪器自动提交错误到您的错误标题下。这对避免提交重复的错误来说是很重要的。小心操作仔细检查避免提交重复的错误。无论如何不要忘记进一步确认您提交的错误是否已经存在。

bug定义

在陈述显而易见的风险，关于一个OpenERP bug的定义这里有几个关键点要注意。

经常被认为是bug：

• 任何系统停止或回溯的错误

• 一个有问题的OpenERP代码导致的任何系统反常表现，在不改变原有功能范围或规格

• 软件代码中的任何安全漏洞

• 经过认证的会计模块中包含的功能违法

通常 不(not) 认为是bug:

• 与客户的特定需求不相符

• 由于错误的安装和设置导致系统异常

• 安全漏洞导致安装或配置存在缺陷

• 该软件的任何使用将不符合一些行业标准.

Everything else is probably either a wishlist or should be made into a blueprint for change/improvement.

Bug 的处理

The following figure depicts the generic Bug Handling Process currently applied at OpenERP, and more specifically on the trunk branch, also known as development version (see also the Bug 管理策略 section)

bug的处理过程被划分成几个连续的主要阶段：

1. Incoming 类BUG则是由整个 OpenERP 社区报告的。

2. Qualification of new bugs is performed by a dedicated team within OpenERP SA, assisted by the Drivers Team, a group of experienced Community Members.

3. Actual bug Resolution is usually performed by the various OpenERP R&D teams, unless the Qualification step was directly able to take care of the fix, for example thanks to a patch contributed along with the bug report.

4. 修复bug的最后一步是发布到官方的trunk分支，并由团队领导好质量团队进行该bug修复的技术和功能的审查。

Bug 的信息

为了正确的认证每个bug，下列性质必须要正确设置：

• 被 影响 的分支必须正确

• the reproducibility of the bug must be verified, as well as the possible duplication (if it’s a duplicate, mark it as such and stop processing it)

• 状态 (status) 必须像下面解释的那样正确设置

• 重要性 (importance) 必须像下面解释的那样正确设置

• 如果Bug确实存在，必须立即或择日解决，需要将其**assigned**给特定的开发团队

• if the bug is not solved yet, the milestone should not be set except by the assigned R&D Team, to indicate when they plan to release the fix

使bug在 新建 (New) 或 确认 (Confirmed) 状态，但是不指定正确的团队也是没有用的。

认定的 Bug 状态

当认定bug之后，必须设定为下列状态之一：

• Confirmed: this means that the bug has been reproduced or is considered valid, and has been accepted. Bugs in this state are considered open. Can be set also for Wishlists that we plan to implement in a future release.

• Incomplete: the bug description does not contain enough information to properly handle it, and prevents from reproducing it (such as missing version, no steps to reproduce, or some other important information missing). Keep in mind that bugs in this state might be updated with a response (in Launchpad bug search you can filter on Incomplete with response or Incomplete without response). As we have enabled auto-bug expiry on Launchpad these bugs will be put in status Expired automatically by Launchpad after 60 days of inactivity, and no answer. Bugs in this state are still considered open until they are Expired.

• Invalid: the bug cannot be reproduced at all or is incorrect, for example because the poster has misunderstood OpenERP’s features or is misusing the system. Bugs in this state are considered closed. Note: If this looks like it could become a Frequently Asked Question, don’t hesitate to Convert to a question before answering (link is on top-right of bug page). This will mark the bug Invalid automatically, and then you can provide the answer on the linked Question.

• Won’t Fix: bugs or wishlists that we can’t or don’t want to fix/implement. Bugs in this state are considered closed.

• Triaged: this status means that the qualifier is not sure if the bug should be confirmed or refused. Set this status and assign a Team to indicate that a Team Leader still needs to confirm/refuse this bug before starting to work on it. Bugs in this state are considered open.

• Fix Released: if you know the bug was valid and has been fixed since it was reported, it may of course be marked directly as such (you may also set the appropriate milestone if you know it)

认定的Bug重要性

Assessing the importance of a bug is a difficult and often subjective task. In order to have common criteria, we propose the following definition for the severity levels on Launchpad bugs

• 严重 (Critical) ：安全问题（例如，累及系统或存在被执行任意代码的可能），或者使系统 对很多用户完全不可用。任何种类的数据丢失。

• High: major part of an application not working correctly and blocking for many users: like the impossibility to display Sale Orders for all users (not just for a peculiar setup, but in most cases)

• Medium: a minor part of an applications not working correctly (not really blocking), or a major feature not working for few users only or for a specific configuration only.

• Low: the rest, mostly usability issues (eg. presentation/layout issues) that don’t prevent to use any of the features.

• Wishlist: nice to have features/patches, propositions to enhance/modify the current logic.

认定的Bug分配

In order to be actually solved, a bug should be assigned to the R&D Team in charge of this area of OpenERP. Each team will assign milestones to indicate when they plan to release the fix for each bug. The main R&D teams and their responsibilities are currently:

• Addons Team 1 is responsible for CRM, Project, Plugins, Knowledge, Tools

• Addons Team 2 is responsible for MRP, Stock, Purchase, Procurement, Marketing

• Addons Team 3 is responsible for Account, Sales, Point of sale, Association, HR

• 框架团队 (Framework Team) 负责服务端框架

• GTK 团队 (GTK Team) 负责本地的 GTK客户端

• Web团队 (Web Team) 负责web界面

里程碑分配

Milestones should be set only for bugs that have been fixed, to track when it happened, or by the R&D team to indicate when they plan to release the fix.

Bug 管理策略

OpenERP Bug Policy

The official OpenERP policy is different depending on the version/branch the bug affects. Bugs reported against the trunk/development branch are all processed as described in the Bug 的处理 section. Bugs reported on a stable branch follow a much stricter qualification process, to limit the risk of regressions on these production-grade versions.

trunk

All bugs and wishlists should be reported on Launchpad, and will be qualified by the OpenERP Launchpad Qualification team. Valid bugs will be confirmed and scheduled for resolution according to their importance. Wishlists will be accepted depending on the R&D strategy, and scheduled in the R&D backlog at the discretion of the R&D Teams.

stable

稳定发行版的bug报告：

• 通过Launchpad反映 高/严重 重要程度的bug （不保证相应时间）

• 通过OpenERP客户的企业渠道 (前出版社保证，依据 contract 保证相应时间）

Valid bugs that also affect trunk will be fixed in trunk, but the fix will only be applied to stable if their importance requires the release of an updated version (security issue, major issue affecting important features, etc.) Anything that looks like a change or improvement will not be accepted on stable.

You will find the complete rationale for this policy below. You may also want to have a look at the Bug 管理 FAQ.

Bug政策的基本原理

As of November 2010, OpenERP has started to enforce a stricter policy, which means that you may be surprised to see that more Launchpad bugs are closed with status Invalid or Won’t Fix. The goal being pursued is to really improve the stability of the stable versions.

OpenERP used to have developers working on all bugs reported via Launchpad, regardless of the OpenERP release they were reported on, and without a strict policy on what is accepted as a bug and what is not. A few years of working in this manner has shown us that this is not efficient, as it leads to long processing times for some bugs, and too often to the introduction of regressions in the stable branches:

• The main trouble with past stable versions was that developers did too many changes on the stable branch and introduced regressions (because the Support/Maintenance team was fixing a maximum of requests on stable branch reported by the community). This was too risky for a stable version.

• Only very few of these changes were impacting customers ; changing a stable branch used by customers in production is always a risk that should be minimized.

• Most of these requests (65% of bugs according to a recent bug qualification sprint) were feature improvements, not bugs.

• The distinction was not clear between bugs fixed through the OpenERP Enterprise contract with a guaranteed response time, and those fixed for free on Launchpad. The Support team did its best to fix both.

In order to improve the situation, OpenERP has split up the teams assigned to the resolution of bugs and the corresponding processes, separating the management of general purpose community bug reports (improving the product for the future) and the management of day-to-day issues encountered on production systems (ensuring stability in a conservative manner):

• The OpenERP Launchpad team is dedicated to processing all bugs reported via Launchpad, qualifying them as quickly as possible, and getting them solved by the R&D teams. They must not touch the stable branches directly, and any important issue reported on a stable branch will be passed on to the OpenERP Enterprise team.

• The OpenERP Enterprise team (formerly OpenERP Publisher’s Warranty) is in charge of receiving issues reported directly by customers via the OpenERP Publisher’s Warranty, providing high-level expertise within short response times, including workarounds and patches when available. They carefully select the fixes to apply to the stable branches, to be published every month.

This way the responsibilities of the teams are clear, and we can appropriately implement continuous improvement, with distinct goals!

Bug 管理 FAQ

1. What is the policy regarding bugs encountered by users of the OpenERP Online Offer?

Customers of OpenERP’s Online Offer are automatically subscribed to an OpenERP Enterprise contract so any bug they report via their dedicated Support/Maintenance channel will be handled accordingly.

2. My Launchpad bug report was refused for the stable release I reported! How can I get it fixed for my important projects/customers?

It is the responsibility of OpenERP Enterprise team (former OpenERP Publisher’s Warranty) to maintain the maximum stability of the stable branches, and this implies being very strict on what can be considered important enough to qualify for a patch on a stable branch.

Note that if the bug affects the trunk as well, you can simply try to apply or backport the fix that was or will be provided for trunk. Other community contributors may also provide patches for the stable branch even if the bug was

3. My Launchpad bug report/feature request was closed as Invalid or Won’t Fix, but I can prove that it really is valid! How can I get it fixed/implemented for my important projects/customers?

This may happen and is not necessarily an error. OpenERP cannot cover all possible cases and does not want to. The idea is to support the most important and common features, and try to avoid becoming overcomplicated or bloated. However OpenERP is also easily extensible and customizable, so you could instead handle your special cases or features in customization modules (if done well and often requested, they could later be included in the official addons)

4. What’s the matter with OpenERP Web Client bugs being all closed as Won’t Fix?

如你注意到的，最近Launchpad上6.0 web客户端系列的bug报告没有得到太多的关注。

The reason is that the OpenERP Web Client from the 6.0 series will not be developed further in the future, as it was becoming too hard to maintain, due to its aging architecture. For the 6.1 series, a new web frontend is under development, rewritten from scratch with a clean (HTML5/Javascript) state-of-the-art architecture. This will make future improvements and maintenance much easier.

The OpenERP Bug Management Policy explains that R&D developers solve bugs reported on Launchpad in the trunk development branch, in order to improve the product for the future, for everyone. As this project will no longer be used in 6.1, these R&D efforts would now be wasted.

Concerning the correction of bugs in the stable series, this is the responsibility of the OpenERP Enterprise (OPW) maintenance team, for all the reasons explained above, and they will of course continue to do it as long as the 6.0 LTS series is supported.

The R&D Web Team can therefore dedicate all its efforts to finishing the new OpenERP 6.1 client, and making it very robust, stable, easy to improve and maintain.