~openerp-community/openobject-doc/ksa-openobject-doc-6.0

« back to all changes in this revision

Viewing changes to i18n/ru/source/contribute/11_bug_tracker.rst

  • Committer: Don Kirkby
  • Date: 2011-02-21 20:46:11 UTC
  • mfrom: (433.1.53 openobject-doc)
  • Revision ID: donkirkby+launpd@gmail.com-20110221204611-1ykt6dmg4k3gh5dh
[MERGE] revisions 477 to 486 from the 5.0 branch.

Show diffs side-by-side

added added

removed removed

Lines of Context:
 
1
 
 
2
.. i18n: .. _bug_management:
 
3
.. i18n: 
 
4
.. i18n: Bug Reports and Bug Processing
 
5
.. i18n: ------------------------------
 
6
..
 
7
 
 
8
.. _bug_management:
 
9
 
 
10
Bug Reports and Bug Processing
 
11
------------------------------
 
12
 
 
13
.. i18n: .. _bug-tracker-link:
 
14
.. i18n: 
 
15
.. i18n: Bug Tracker
 
16
.. i18n: +++++++++++
 
17
..
 
18
 
 
19
.. _bug-tracker-link:
 
20
 
 
21
Bug Tracker
 
22
+++++++++++
 
23
 
 
24
.. i18n: As described in the :ref:`community_platform` section, OpenERP uses
 
25
.. i18n: Launchpad as the bug tracker platform.
 
26
..
 
27
 
 
28
As described in the :ref:`community_platform` section, OpenERP uses
 
29
Launchpad as the bug tracker platform.
 
30
 
 
31
.. i18n: Anyone is free to report new bugs or give feedback on existing ones
 
32
.. i18n: in OpenERP's Launchpad bugtracker.
 
33
.. i18n: The only requirement is to `sign up on Launchpad <https://login.launchpad.net/+new_account>`_ 
 
34
.. i18n: and join the `OpenERP Community <https://launchpad.net/~openerp-community/+join>`_ team,
 
35
.. i18n: which only requires a few clicks.
 
36
..
 
37
 
 
38
Anyone is free to report new bugs or give feedback on existing ones
 
39
in OpenERP's Launchpad bugtracker.
 
40
The only requirement is to `sign up on Launchpad <https://login.launchpad.net/+new_account>`_ 
 
41
and join the `OpenERP Community <https://launchpad.net/~openerp-community/+join>`_ team,
 
42
which only requires a few clicks.
 
43
 
 
44
.. i18n: .. note:: Some additional team memberships are required in order to accomplish specific
 
45
.. i18n:           tasks, as explained in the :ref:`bug_processing` section below.
 
46
..
 
47
 
 
48
.. note:: Some additional team memberships are required in order to accomplish specific
 
49
          tasks, as explained in the :ref:`bug_processing` section below.
 
50
 
 
51
.. i18n: Any issue you notice in OpenERP should be reported on the appropriate
 
52
.. i18n: project on LaunchPad. A link to report a new bug can be found on the 
 
53
.. i18n: top right side of the homepage of each Launchpad project.
 
54
.. i18n: Here is a quick overview of the direct links for reporting bugs on
 
55
.. i18n: each OpenERP project:
 
56
..
 
57
 
 
58
Any issue you notice in OpenERP should be reported on the appropriate
 
59
project on LaunchPad. A link to report a new bug can be found on the 
 
60
top right side of the homepage of each Launchpad project.
 
61
Here is a quick overview of the direct links for reporting bugs on
 
62
each OpenERP project:
 
63
 
 
64
.. i18n: +---------------------+-------------------------------------------------+
 
65
.. i18n: | Project             | Bug report interface                            |
 
66
.. i18n: +---------------------+-------------------------------------------------+
 
67
.. i18n: | OpenERP Addons      | http://bugs.launchpad.net/openobject-addons     |
 
68
.. i18n: +---------------------+-------------------------------------------------+
 
69
.. i18n: | OpenERP Server      | http://bugs.launchpad.net/openobject-server     |
 
70
.. i18n: +---------------------+-------------------------------------------------+
 
71
.. i18n: | OpenERP GTK Client  | http://bugs.launchpad.net/openobject-client     |
 
72
.. i18n: +---------------------+-------------------------------------------------+
 
73
.. i18n: | OpenERP Web         | http://bugs.launchpad.net/openobject-client-web |
 
74
.. i18n: +---------------------+-------------------------------------------------+
 
75
..
 
76
 
 
77
+---------------------+-------------------------------------------------+
 
78
| Project             | Bug report interface                            |
 
79
+---------------------+-------------------------------------------------+
 
80
| OpenERP Addons      | http://bugs.launchpad.net/openobject-addons     |
 
81
+---------------------+-------------------------------------------------+
 
82
| OpenERP Server      | http://bugs.launchpad.net/openobject-server     |
 
83
+---------------------+-------------------------------------------------+
 
84
| OpenERP GTK Client  | http://bugs.launchpad.net/openobject-client     |
 
85
+---------------------+-------------------------------------------------+
 
86
| OpenERP Web         | http://bugs.launchpad.net/openobject-client-web |
 
87
+---------------------+-------------------------------------------------+
 
88
 
 
89
.. i18n: .. important::
 
90
.. i18n: 
 
91
.. i18n:     The LaunchPad bug tracker automatically proposes bugs that look
 
92
.. i18n:     similar to your bug title when you attempt to report a new one.
 
93
.. i18n:     This is important to avoid reporting several times the same bug.
 
94
.. i18n:     Be careful to double-check the proposed bugs, so you avoid
 
95
.. i18n:     creating duplicates. However do not forget to proceed further
 
96
.. i18n:     should none of the existing bugs match yours.
 
97
..
 
98
 
 
99
.. important::
 
100
 
 
101
    The LaunchPad bug tracker automatically proposes bugs that look
 
102
    similar to your bug title when you attempt to report a new one.
 
103
    This is important to avoid reporting several times the same bug.
 
104
    Be careful to double-check the proposed bugs, so you avoid
 
105
    creating duplicates. However do not forget to proceed further
 
106
    should none of the existing bugs match yours.
 
107
 
 
108
.. i18n: .. _bug_definition:
 
109
.. i18n: 
 
110
.. i18n: Definition of a bug
 
111
.. i18n: +++++++++++++++++++
 
112
.. i18n: At the risk of stating the obvious, here are a few key points to keep in mind
 
113
.. i18n: concerning the definition of an OpenERP bug.
 
114
..
 
115
 
 
116
.. _bug_definition:
 
117
 
 
118
Definition of a bug
 
119
+++++++++++++++++++
 
120
At the risk of stating the obvious, here are a few key points to keep in mind
 
121
concerning the definition of an OpenERP bug.
 
122
 
 
123
.. i18n: Is usually considered a bug:
 
124
..
 
125
 
 
126
Is usually considered a bug:
 
127
 
 
128
.. i18n:     * Any system failure with a complete stop or traceback
 
129
.. i18n:     * Any abnormal behavior of the system resulting from an
 
130
.. i18n:       issue with OpenERP code, without changing the original
 
131
.. i18n:       functional scope or specification
 
132
.. i18n:     * Any security breach in the code of the software
 
133
.. i18n:     * Non compliance with the law for an existing feature
 
134
.. i18n:       of a certified accounting module
 
135
..
 
136
 
 
137
    * Any system failure with a complete stop or traceback
 
138
    * Any abnormal behavior of the system resulting from an
 
139
      issue with OpenERP code, without changing the original
 
140
      functional scope or specification
 
141
    * Any security breach in the code of the software
 
142
    * Non compliance with the law for an existing feature
 
143
      of a certified accounting module
 
144
 
 
145
.. i18n: Is usually **not** considered a bug:
 
146
..
 
147
 
 
148
Is usually **not** considered a bug:
 
149
 
 
150
.. i18n:     * Non compliance with a customer specific need
 
151
.. i18n:     * Abnormal system behavior due to defective
 
152
.. i18n:       installation or configuration
 
153
.. i18n:     * Security breach resulting from defective 
 
154
.. i18n:       installation or configuration
 
155
.. i18n:     * Any usage of the software which would not 
 
156
.. i18n:       comply with some industry standard
 
157
..
 
158
 
 
159
    * Non compliance with a customer specific need
 
160
    * Abnormal system behavior due to defective
 
161
      installation or configuration
 
162
    * Security breach resulting from defective 
 
163
      installation or configuration
 
164
    * Any usage of the software which would not 
 
165
      comply with some industry standard
 
166
 
 
167
.. i18n: Everything else is probably either a wishlist or should be made into
 
168
.. i18n: a blueprint for change/improvement.
 
169
..
 
170
 
 
171
Everything else is probably either a wishlist or should be made into
 
172
a blueprint for change/improvement.
 
173
 
 
174
.. i18n: .. _bug_processing:
 
175
.. i18n: 
 
176
.. i18n: Bug Processing
 
177
.. i18n: ++++++++++++++
 
178
..
 
179
 
 
180
.. _bug_processing:
 
181
 
 
182
Bug Processing
 
183
++++++++++++++
 
184
 
 
185
.. i18n: The following figure depicts the generic Bug Handling Process currently applied
 
186
.. i18n: at OpenERP, and more specifically on the **trunk** branch,
 
187
.. i18n: also known as **development version** (see also the :ref:`bug_policy` section)
 
188
..
 
189
 
 
190
The following figure depicts the generic Bug Handling Process currently applied
 
191
at OpenERP, and more specifically on the **trunk** branch,
 
192
also known as **development version** (see also the :ref:`bug_policy` section)
 
193
 
 
194
.. i18n: .. figure:: bug_management.png
 
195
.. i18n:     :alt: Bug Management Process
 
196
..
 
197
 
 
198
.. figure:: bug_management.png
 
199
    :alt: Bug Management Process
 
200
 
 
201
.. i18n: The processing of bugs is divided up into several successive main stages:
 
202
..
 
203
 
 
204
The processing of bugs is divided up into several successive main stages:
 
205
 
 
206
.. i18n:     #. **Incoming** bugs are reported on Launchpad by the whole OpenERP Community
 
207
.. i18n:     #. **Qualification** of new bugs is performed by a dedicated team within
 
208
.. i18n:        OpenERP SA, assisted by the `Drivers Team <https://launchpad.net/openerp-drivers>`_,
 
209
.. i18n:        a group of experienced Community Members.
 
210
.. i18n:     #. Actual bug **Resolution** is usually performed by the various OpenERP R&D teams,
 
211
.. i18n:        unless the **Qualification** step was directly able to take care of the fix,
 
212
.. i18n:        for example thanks to a :ref:`patch <merge_proposals>` contributed along with the bug report.
 
213
.. i18n:     #. The last step before a bugfix is fully released into the official trunk
 
214
.. i18n:        branches is a final technical and functional review of the fix by the
 
215
.. i18n:        Team Leader and/or the Quality Team.
 
216
..
 
217
 
 
218
    #. **Incoming** bugs are reported on Launchpad by the whole OpenERP Community
 
219
    #. **Qualification** of new bugs is performed by a dedicated team within
 
220
       OpenERP SA, assisted by the `Drivers Team <https://launchpad.net/openerp-drivers>`_,
 
221
       a group of experienced Community Members.
 
222
    #. Actual bug **Resolution** is usually performed by the various OpenERP R&D teams,
 
223
       unless the **Qualification** step was directly able to take care of the fix,
 
224
       for example thanks to a :ref:`patch <merge_proposals>` contributed along with the bug report.
 
225
    #. The last step before a bugfix is fully released into the official trunk
 
226
       branches is a final technical and functional review of the fix by the
 
227
       Team Leader and/or the Quality Team.
 
228
 
 
229
.. i18n: Bug Qualification
 
230
.. i18n: *****************
 
231
.. i18n: In order to properly qualify each bug, the following attributes must be
 
232
.. i18n: properly set:
 
233
..
 
234
 
 
235
Bug Qualification
 
236
*****************
 
237
In order to properly qualify each bug, the following attributes must be
 
238
properly set:
 
239
 
 
240
.. i18n:     * the branch(es) it's **affecting** must be correct
 
241
.. i18n:     * the *reproducibility* of the bug must be verified, as well as the possible
 
242
.. i18n:       duplication (if it's a duplicate, mark it as such and stop processing it)
 
243
.. i18n:     * the **status** must be correctly set, as explained in the next section
 
244
.. i18n:     * the **importance** must be correctly set, as explained in the next section
 
245
.. i18n:     * if the bug is valid and must be solved (now or in the future), it must
 
246
.. i18n:       be **assigned** to the corresponding R&D Team
 
247
.. i18n:     * if the bug is not solved yet, the **milestone** should **not** be set except
 
248
.. i18n:       by the assigned R&D Team, to indicate when they plan to release the fix
 
249
..
 
250
 
 
251
    * the branch(es) it's **affecting** must be correct
 
252
    * the *reproducibility* of the bug must be verified, as well as the possible
 
253
      duplication (if it's a duplicate, mark it as such and stop processing it)
 
254
    * the **status** must be correctly set, as explained in the next section
 
255
    * the **importance** must be correctly set, as explained in the next section
 
256
    * if the bug is valid and must be solved (now or in the future), it must
 
257
      be **assigned** to the corresponding R&D Team
 
258
    * if the bug is not solved yet, the **milestone** should **not** be set except
 
259
      by the assigned R&D Team, to indicate when they plan to release the fix
 
260
 
 
261
.. i18n: Leaving a bug as **New** or **Confirmed**, but not assigning a proper Team is
 
262
.. i18n: not useful.
 
263
..
 
264
 
 
265
Leaving a bug as **New** or **Confirmed**, but not assigning a proper Team is
 
266
not useful.
 
267
 
 
268
.. i18n: .. rubric:: Qualified Bug Status
 
269
..
 
270
 
 
271
.. rubric:: Qualified Bug Status
 
272
 
 
273
.. i18n: One of the following status values must be set on a bug when qualifying it:
 
274
..
 
275
 
 
276
One of the following status values must be set on a bug when qualifying it:
 
277
 
 
278
.. i18n:     * **Confirmed**: this means that the bug has been reproduced or is considered valid,
 
279
.. i18n:       and has been accepted. Bugs in this state are considered *open*. Can be set also for
 
280
.. i18n:       Wishlists that we plan to implement in a future release.
 
281
.. i18n:     * **Incomplete**: the bug description does not contain enough information to properly
 
282
.. i18n:       handle it, and prevents from reproducing it (such as missing version, no steps to
 
283
.. i18n:       reproduce, or some other important information missing).
 
284
.. i18n:       Keep in mind that bugs in this state might be updated with a response
 
285
.. i18n:       (in Launchpad bug search you can filter on *Incomplete with response* or *Incomplete without response*).
 
286
.. i18n:       As we have enabled auto-bug expiry on Launchpad these bugs will be put in status *Expired*
 
287
.. i18n:       automatically by Launchpad after 60 days of inactivity, and no answer.
 
288
.. i18n:       Bugs in this state are still considered open until they are Expired.
 
289
.. i18n:     * **Invalid**: the bug cannot be reproduced at all or is incorrect, for example because
 
290
.. i18n:       the poster has misunderstood OpenERP's features or is misusing the system.
 
291
.. i18n:       Bugs in this state are considered closed.
 
292
.. i18n:       Note: If this looks like it could become a Frequently Asked Question, don't hesitate to
 
293
.. i18n:       *Convert to a question* before answering (link is on top-right of bug page).
 
294
.. i18n:       This will mark the bug *Invalid* automatically, and then you can provide the answer on
 
295
.. i18n:       the linked Question. (Note: converting to a question sometimes fails at the moment due to
 
296
.. i18n:       a `Launchpad bug <https://bugs.launchpad.net/bugs/438116>`_)
 
297
.. i18n:     * **Won't Fix**: bugs or wishlists that we can't or don't
 
298
.. i18n:       want to fix/implement them. Bugs in this state are considered closed.
 
299
.. i18n:     * **Triaged**: this status means that the qualifier is not sure if the bug should be
 
300
.. i18n:       confirmed or refused. Set this status and assign a Team to indicate that a Team Leader still
 
301
.. i18n:       needs to confirm/refuse this bug before starting to work on it.
 
302
.. i18n:       Bugs in this state are considered open.
 
303
.. i18n:     * **Fix Released**: if you know the bug was valid bug has been fixed since it was reported,
 
304
.. i18n:       it may of course be marked directly as such (you may also set the appropriate mileston
 
305
.. i18n:       if you know it) 
 
306
..
 
307
 
 
308
    * **Confirmed**: this means that the bug has been reproduced or is considered valid,
 
309
      and has been accepted. Bugs in this state are considered *open*. Can be set also for
 
310
      Wishlists that we plan to implement in a future release.
 
311
    * **Incomplete**: the bug description does not contain enough information to properly
 
312
      handle it, and prevents from reproducing it (such as missing version, no steps to
 
313
      reproduce, or some other important information missing).
 
314
      Keep in mind that bugs in this state might be updated with a response
 
315
      (in Launchpad bug search you can filter on *Incomplete with response* or *Incomplete without response*).
 
316
      As we have enabled auto-bug expiry on Launchpad these bugs will be put in status *Expired*
 
317
      automatically by Launchpad after 60 days of inactivity, and no answer.
 
318
      Bugs in this state are still considered open until they are Expired.
 
319
    * **Invalid**: the bug cannot be reproduced at all or is incorrect, for example because
 
320
      the poster has misunderstood OpenERP's features or is misusing the system.
 
321
      Bugs in this state are considered closed.
 
322
      Note: If this looks like it could become a Frequently Asked Question, don't hesitate to
 
323
      *Convert to a question* before answering (link is on top-right of bug page).
 
324
      This will mark the bug *Invalid* automatically, and then you can provide the answer on
 
325
      the linked Question. (Note: converting to a question sometimes fails at the moment due to
 
326
      a `Launchpad bug <https://bugs.launchpad.net/bugs/438116>`_)
 
327
    * **Won't Fix**: bugs or wishlists that we can't or don't
 
328
      want to fix/implement them. Bugs in this state are considered closed.
 
329
    * **Triaged**: this status means that the qualifier is not sure if the bug should be
 
330
      confirmed or refused. Set this status and assign a Team to indicate that a Team Leader still
 
331
      needs to confirm/refuse this bug before starting to work on it.
 
332
      Bugs in this state are considered open.
 
333
    * **Fix Released**: if you know the bug was valid bug has been fixed since it was reported,
 
334
      it may of course be marked directly as such (you may also set the appropriate mileston
 
335
      if you know it) 
 
336
 
 
337
.. i18n: .. rubric:: Qualified Bug Importance
 
338
..
 
339
 
 
340
.. rubric:: Qualified Bug Importance
 
341
 
 
342
.. i18n: Assessing the importance of a bug is a difficult and often subjective task.
 
343
.. i18n: In order to have common criterions, we propose the following definition
 
344
.. i18n: for the severity levels on Launchpad bugs
 
345
..
 
346
 
 
347
Assessing the importance of a bug is a difficult and often subjective task.
 
348
In order to have common criterions, we propose the following definition
 
349
for the severity levels on Launchpad bugs
 
350
 
 
351
.. i18n:     * **Critical**: security issue (e.g. system compromised or arbitrary 
 
352
.. i18n:       code execution possible), or system completely unusable, for many users. 
 
353
.. i18n:       Any kind of data loss.
 
354
.. i18n:     * **High**: major part of an application not working correctly and blocking
 
355
.. i18n:       for many users: like the impossibility to display Sale Orders
 
356
.. i18n:       for all users (not just for a peculiar setup, but in most cases)
 
357
.. i18n:     * **Medium**: a minor part of an applications not working correctly (not
 
358
.. i18n:       really blocking), or a major feature not working for few users only
 
359
.. i18n:       or for a specific configuration only.
 
360
.. i18n:     * **Low**: the rest, mostly usability issues (eg. presentation/layout issues)
 
361
.. i18n:       that don't prevent to use any of the features.
 
362
.. i18n:     * **Wishlist**: nice to have features/patches, propositions to enhance/modify
 
363
.. i18n:       the current logic.
 
364
..
 
365
 
 
366
    * **Critical**: security issue (e.g. system compromised or arbitrary 
 
367
      code execution possible), or system completely unusable, for many users. 
 
368
      Any kind of data loss.
 
369
    * **High**: major part of an application not working correctly and blocking
 
370
      for many users: like the impossibility to display Sale Orders
 
371
      for all users (not just for a peculiar setup, but in most cases)
 
372
    * **Medium**: a minor part of an applications not working correctly (not
 
373
      really blocking), or a major feature not working for few users only
 
374
      or for a specific configuration only.
 
375
    * **Low**: the rest, mostly usability issues (eg. presentation/layout issues)
 
376
      that don't prevent to use any of the features.
 
377
    * **Wishlist**: nice to have features/patches, propositions to enhance/modify
 
378
      the current logic.
 
379
 
 
380
.. i18n: .. rubric:: Qualified Bug Assignation
 
381
..
 
382
 
 
383
.. rubric:: Qualified Bug Assignation
 
384
 
 
385
.. i18n: In order to be actually solved, a bug should be assigned to the R&D Team in charge
 
386
.. i18n: of this area of OpenERP. Each team will assign milestones to indicate when they
 
387
.. i18n: plan to release the fix for each bug. The main R&D teams and their responsibilities
 
388
.. i18n: are currently:
 
389
..
 
390
 
 
391
In order to be actually solved, a bug should be assigned to the R&D Team in charge
 
392
of this area of OpenERP. Each team will assign milestones to indicate when they
 
393
plan to release the fix for each bug. The main R&D teams and their responsibilities
 
394
are currently:
 
395
 
 
396
.. i18n:     * `Addons Team 1 <http://launchpad.net/~openerp-dev-addons1>`_ is responsible for CRM, Project, Plugins, Knowledge, Tools
 
397
.. i18n:     * `Addons Team 2 <http://launchpad.net/~openerp-dev-addons2>`_ is responsible for MRP, Stock, Purchase, Procurement, Marketing
 
398
.. i18n:     * `Addons Team 3 <http://launchpad.net/~openerp-dev-addons3>`_ is responsible for Account, Sales, Point of sale, Association, HR
 
399
.. i18n:     * `Framework Team <http://launchpad.net/~openerp-dev-framework>`_ is responsible for the Server/Framework
 
400
.. i18n:     * `GTK Team <http://launchpad.net/~openerp-dev-gtk>`_ is responsible for the GTK Native Client
 
401
.. i18n:     * `Web Team <http://launchpad.net/~openerp-dev-web>`_ is responsible for the Web Interface
 
402
..
 
403
 
 
404
    * `Addons Team 1 <http://launchpad.net/~openerp-dev-addons1>`_ is responsible for CRM, Project, Plugins, Knowledge, Tools
 
405
    * `Addons Team 2 <http://launchpad.net/~openerp-dev-addons2>`_ is responsible for MRP, Stock, Purchase, Procurement, Marketing
 
406
    * `Addons Team 3 <http://launchpad.net/~openerp-dev-addons3>`_ is responsible for Account, Sales, Point of sale, Association, HR
 
407
    * `Framework Team <http://launchpad.net/~openerp-dev-framework>`_ is responsible for the Server/Framework
 
408
    * `GTK Team <http://launchpad.net/~openerp-dev-gtk>`_ is responsible for the GTK Native Client
 
409
    * `Web Team <http://launchpad.net/~openerp-dev-web>`_ is responsible for the Web Interface
 
410
 
 
411
.. i18n: .. rubric:: Milestone Assignation
 
412
..
 
413
 
 
414
.. rubric:: Milestone Assignation
 
415
 
 
416
.. i18n: Milestones should be set only for bugs that have been fixed, to track when it happened,
 
417
.. i18n: or by the R&D team to indicate when they plan to release the fix.
 
418
..
 
419
 
 
420
Milestones should be set only for bugs that have been fixed, to track when it happened,
 
421
or by the R&D team to indicate when they plan to release the fix.
 
422
 
 
423
.. i18n: .. _bug_policy:
 
424
.. i18n: 
 
425
.. i18n: Bug Management Policy
 
426
.. i18n: ++++++++++++++++++++++
 
427
..
 
428
 
 
429
.. _bug_policy:
 
430
 
 
431
Bug Management Policy
 
432
++++++++++++++++++++++
 
433
 
 
434
.. i18n: .. topic:: OpenERP Bug Policy
 
435
.. i18n: 
 
436
.. i18n:     The official OpenERP policy is different depending on the version/branch the bug affects.
 
437
.. i18n:     Bugs reported against the **trunk/development** branch are all processed as described in the
 
438
.. i18n:     :ref:`bug_processing` section. Bugs reported on a **stable** branch follow a much stricter
 
439
.. i18n:     qualification process, to limit the risk of regressions on these production-grade versions.
 
440
.. i18n: 
 
441
.. i18n:         .. rubric:: **trunk**
 
442
.. i18n: 
 
443
.. i18n:         All bugs and wishlists should be reported on Launchpad, and 
 
444
.. i18n:         will be qualified by the OpenERP Launchpad Qualification
 
445
.. i18n:         team. :ref:`Valid bugs <bug_definition>` will be confirmed and scheduled for
 
446
.. i18n:         resolution according to their importance. Wishlists will be
 
447
.. i18n:         accepted depending on the R&D strategy, and scheduled in the
 
448
.. i18n:         R&D backlog at the discretion of the R&D Teams.
 
449
.. i18n: 
 
450
.. i18n:         .. rubric:: **stable**
 
451
.. i18n: 
 
452
.. i18n:         Bugs on stable releases may be reported:
 
453
.. i18n: 
 
454
.. i18n:             + via Launchpad (no guaranteed response time)
 
455
.. i18n:             + via the Publisher's Warranty channel for Customers (guaranteed response
 
456
.. i18n:               time according to the `contract <http://www.openerp.com/services/subscribe-onsite>`_)
 
457
.. i18n: 
 
458
.. i18n:         :ref:`Valid bugs <bug_definition>` that also affect trunk
 
459
.. i18n:         will be fixed in trunk, but the fix will only be applied to
 
460
.. i18n:         stable if their importance requires the release of an updated version (security issue,
 
461
.. i18n:         major issue affecting important features, etc.) Anything that looks
 
462
.. i18n:         like a change or improvement will not be accepted on stable.
 
463
.. i18n: 
 
464
.. i18n:     You will find the complete rationale for this policy below. You may also want to have
 
465
.. i18n:     a look at the :ref:`bug_policy_faq`.
 
466
..
 
467
 
 
468
.. topic:: OpenERP Bug Policy
 
469
 
 
470
    The official OpenERP policy is different depending on the version/branch the bug affects.
 
471
    Bugs reported against the **trunk/development** branch are all processed as described in the
 
472
    :ref:`bug_processing` section. Bugs reported on a **stable** branch follow a much stricter
 
473
    qualification process, to limit the risk of regressions on these production-grade versions.
 
474
 
 
475
        .. rubric:: **trunk**
 
476
 
 
477
        All bugs and wishlists should be reported on Launchpad, and 
 
478
        will be qualified by the OpenERP Launchpad Qualification
 
479
        team. :ref:`Valid bugs <bug_definition>` will be confirmed and scheduled for
 
480
        resolution according to their importance. Wishlists will be
 
481
        accepted depending on the R&D strategy, and scheduled in the
 
482
        R&D backlog at the discretion of the R&D Teams.
 
483
 
 
484
        .. rubric:: **stable**
 
485
 
 
486
        Bugs on stable releases may be reported:
 
487
 
 
488
            + via Launchpad (no guaranteed response time)
 
489
            + via the Publisher's Warranty channel for Customers (guaranteed response
 
490
              time according to the `contract <http://www.openerp.com/services/subscribe-onsite>`_)
 
491
 
 
492
        :ref:`Valid bugs <bug_definition>` that also affect trunk
 
493
        will be fixed in trunk, but the fix will only be applied to
 
494
        stable if their importance requires the release of an updated version (security issue,
 
495
        major issue affecting important features, etc.) Anything that looks
 
496
        like a change or improvement will not be accepted on stable.
 
497
 
 
498
    You will find the complete rationale for this policy below. You may also want to have
 
499
    a look at the :ref:`bug_policy_faq`.
 
500
 
 
501
.. i18n: .. rubric:: Rationale for the Bug Policy
 
502
..
 
503
 
 
504
.. rubric:: Rationale for the Bug Policy
 
505
 
 
506
.. i18n: As of november 2010, OpenERP has started to enforce a stricter policy, which
 
507
.. i18n: means that you may be surprised to see that more Launchpad bugs are
 
508
.. i18n: closed with status *Invalid* or *Won't Fix*. The goal being pursued is to
 
509
.. i18n: really improve the stability of the stable versions.
 
510
..
 
511
 
 
512
As of november 2010, OpenERP has started to enforce a stricter policy, which
 
513
means that you may be surprised to see that more Launchpad bugs are
 
514
closed with status *Invalid* or *Won't Fix*. The goal being pursued is to
 
515
really improve the stability of the stable versions.
 
516
 
 
517
.. i18n: OpenERP used to have developers working on all bugs reported via Launchpad,
 
518
.. i18n: regardless of the OpenERP release they were reported on, and without a strict
 
519
.. i18n: policy on what is accepted as a bug and what is not.
 
520
.. i18n: A few years of working in this manner has shown us that this is not efficient,
 
521
.. i18n: as it leads to long processing times for some bugs, and too often to the introduction
 
522
.. i18n: of regressions in the stable branches:
 
523
..
 
524
 
 
525
OpenERP used to have developers working on all bugs reported via Launchpad,
 
526
regardless of the OpenERP release they were reported on, and without a strict
 
527
policy on what is accepted as a bug and what is not.
 
528
A few years of working in this manner has shown us that this is not efficient,
 
529
as it leads to long processing times for some bugs, and too often to the introduction
 
530
of regressions in the stable branches:
 
531
 
 
532
.. i18n:     - The main trouble with past stable versions
 
533
.. i18n:       was that developers did too much changes on
 
534
.. i18n:       the stable branch and introduced regressions (because
 
535
.. i18n:       the Support/Maintenance team was fixing a maximum of requests
 
536
.. i18n:       on stable branch reported by the
 
537
.. i18n:       community). This was too risky for a stable version.
 
538
.. i18n:     - Only very few of these changes were impacting customers ;
 
539
.. i18n:       changing a stable branch used by customers in production is always a
 
540
.. i18n:       risk that should be minimized.
 
541
.. i18n:     - Most of these requests (evaluated to 65% of bugs according to a
 
542
.. i18n:       recent bug qualification sprint) were feature improvements, not bugs.
 
543
.. i18n:     - The distinction was not clear between bugs fixed through the
 
544
.. i18n:       Publisher's Warranty contract with a guaranteed response time, 
 
545
.. i18n:       and those fixed for free on Launchpad. The Support team did its
 
546
.. i18n:       best to fix both.
 
547
..
 
548
 
 
549
    - The main trouble with past stable versions
 
550
      was that developers did too much changes on
 
551
      the stable branch and introduced regressions (because
 
552
      the Support/Maintenance team was fixing a maximum of requests
 
553
      on stable branch reported by the
 
554
      community). This was too risky for a stable version.
 
555
    - Only very few of these changes were impacting customers ;
 
556
      changing a stable branch used by customers in production is always a
 
557
      risk that should be minimized.
 
558
    - Most of these requests (evaluated to 65% of bugs according to a
 
559
      recent bug qualification sprint) were feature improvements, not bugs.
 
560
    - The distinction was not clear between bugs fixed through the
 
561
      Publisher's Warranty contract with a guaranteed response time, 
 
562
      and those fixed for free on Launchpad. The Support team did its
 
563
      best to fix both.
 
564
 
 
565
.. i18n: In order to improve the situation, OpenERP has split up the teams assigned to the resolution of bugs
 
566
.. i18n: and the corresponding processes, separating the management of general purpose
 
567
.. i18n: community bug reports (improving the product for the future) and the management
 
568
.. i18n: of day-to-day issues encountered on production systems
 
569
.. i18n: (ensuring stability in a conservative manner):
 
570
..
 
571
 
 
572
In order to improve the situation, OpenERP has split up the teams assigned to the resolution of bugs
 
573
and the corresponding processes, separating the management of general purpose
 
574
community bug reports (improving the product for the future) and the management
 
575
of day-to-day issues encountered on production systems
 
576
(ensuring stability in a conservative manner):
 
577
 
 
578
.. i18n:     * The **OpenERP Launchpad team** is dedicated to processing all bugs reported via
 
579
.. i18n:       Launchpad, qualifying them as quickly as possible, and getting them solved
 
580
.. i18n:       by the R&D teams. They must not touch the stable branches directly, and any
 
581
.. i18n:       important issue reported on a stable branch will be passed on to the
 
582
.. i18n:       **OpenERP Publisher's Warranty team**.
 
583
.. i18n: 
 
584
.. i18n:     * The **OpenERP Publisher's Warranty team** is in charge of receiving issues reported
 
585
.. i18n:       directly by customers via the OpenERP Publisher's Warranty, providing high-level
 
586
.. i18n:       expertise within short response times, including workarounds and patches when available.
 
587
.. i18n:       They carefully select the fixes to apply to the stable branches, to be published
 
588
.. i18n:       every month.
 
589
..
 
590
 
 
591
    * The **OpenERP Launchpad team** is dedicated to processing all bugs reported via
 
592
      Launchpad, qualifying them as quickly as possible, and getting them solved
 
593
      by the R&D teams. They must not touch the stable branches directly, and any
 
594
      important issue reported on a stable branch will be passed on to the
 
595
      **OpenERP Publisher's Warranty team**.
 
596
 
 
597
    * The **OpenERP Publisher's Warranty team** is in charge of receiving issues reported
 
598
      directly by customers via the OpenERP Publisher's Warranty, providing high-level
 
599
      expertise within short response times, including workarounds and patches when available.
 
600
      They carefully select the fixes to apply to the stable branches, to be published
 
601
      every month.
 
602
 
 
603
.. i18n: This way the responsabilities of the teams are clear, and we can appropriately
 
604
.. i18n: implement continuous improvement, with distinct **goals**!
 
605
..
 
606
 
 
607
This way the responsabilities of the teams are clear, and we can appropriately
 
608
implement continuous improvement, with distinct **goals**!
 
609
 
 
610
.. i18n: .. _bug_policy_faq:
 
611
.. i18n: 
 
612
.. i18n: Bug Management FAQ
 
613
.. i18n: ******************
 
614
.. i18n: .. topic:: What is the policy regarding bugs encountered by users of the OpenERP Online Offer?
 
615
.. i18n: 
 
616
.. i18n:     Customers of `OpenERP's Online Offer <http://www.openerp.com/services>`_ are automatically
 
617
.. i18n:     subscribed to an OpenERP Publisher's Warranty contract so any bug they report via their
 
618
.. i18n:     dedicated Support/Maintenance channel will be handled accordingly.
 
619
..
 
620
 
 
621
.. _bug_policy_faq:
 
622
 
 
623
Bug Management FAQ
 
624
******************
 
625
.. topic:: What is the policy regarding bugs encountered by users of the OpenERP Online Offer?
 
626
 
 
627
    Customers of `OpenERP's Online Offer <http://www.openerp.com/services>`_ are automatically
 
628
    subscribed to an OpenERP Publisher's Warranty contract so any bug they report via their
 
629
    dedicated Support/Maintenance channel will be handled accordingly.
 
630
 
 
631
.. i18n: .. topic:: My Launchpad bug report was refused for the stable release I reported! How can I get it
 
632
.. i18n:            fixed for my important projects/customers?
 
633
.. i18n: 
 
634
.. i18n:    It is the responsibility of OpenERP Publisher's Warranty team to maintain the maximum stability
 
635
.. i18n:    of the stable branches, and this implies being very strict on what can be considered important
 
636
.. i18n:    enough to be worth the application of a patch on a stable branch.
 
637
.. i18n: 
 
638
.. i18n:    Note that if the bug affects the trunk as well, you can simply try to apply or backport the fix that was
 
639
.. i18n:    or will be provided for trunk. Other community contributors may also provide patches for the stable
 
640
.. i18n:    branch even if the bug was 
 
641
..
 
642
 
 
643
.. topic:: My Launchpad bug report was refused for the stable release I reported! How can I get it
 
644
           fixed for my important projects/customers?
 
645
 
 
646
   It is the responsibility of OpenERP Publisher's Warranty team to maintain the maximum stability
 
647
   of the stable branches, and this implies being very strict on what can be considered important
 
648
   enough to be worth the application of a patch on a stable branch.
 
649
 
 
650
   Note that if the bug affects the trunk as well, you can simply try to apply or backport the fix that was
 
651
   or will be provided for trunk. Other community contributors may also provide patches for the stable
 
652
   branch even if the bug was 
 
653
 
 
654
.. i18n: .. topic:: My Launchpad bug report/feature request was closed as Invalid or Won't Fix, but I can prove that
 
655
.. i18n:            it really is valid! How can I get it fixed/implemented for my important projects/customers?
 
656
.. i18n: 
 
657
.. i18n:    This may happen and is not necessarily an error. OpenERP cannot cover all possible cases and does
 
658
.. i18n:    not want to. The idea is to support the most important and common features, and try to avoid
 
659
.. i18n:    becoming overcomplicated or bloated.
 
660
.. i18n:    However OpenERP is also easily extensible and customizable, so you could instead handle your
 
661
.. i18n:    special cases or features in customization modules (if done well and often requested,
 
662
.. i18n:    they could later be included in the official addons)
 
663
..
 
664
 
 
665
.. topic:: My Launchpad bug report/feature request was closed as Invalid or Won't Fix, but I can prove that
 
666
           it really is valid! How can I get it fixed/implemented for my important projects/customers?
 
667
 
 
668
   This may happen and is not necessarily an error. OpenERP cannot cover all possible cases and does
 
669
   not want to. The idea is to support the most important and common features, and try to avoid
 
670
   becoming overcomplicated or bloated.
 
671
   However OpenERP is also easily extensible and customizable, so you could instead handle your
 
672
   special cases or features in customization modules (if done well and often requested,
 
673
   they could later be included in the official addons)