openerp-dev team mailing list archive

[Olivier Dony <odo@xxxxxxxxxxx>]

Hello everyone,

This is specifically important for the teams in charge of Launchpad  and 
Support, but it is important for everyone to at least be aware of these 
topics.


A. We have recently revised the bug policy described in the official 
documentation here, following community feedback:
   http://doc.openerp.com/contribute/11_bug_tracker.html

The main change is that instead of always refusing bug reports on stable 
via Launchpad, we now say we will only accept them if we consider them 
important enough to be worth a patch to the stable release. The idea is 
to be very strict in what is patched in stable versions to make them as 
stable as possible! (regardless if bug/patch was provided via 
maintenance or LP)
The difference with maintenance is of course the service: response time, 
more time spent to provide answer or workaround, patch may be provided 
even if we can't apply on trunk, etc.

This means that the bug qualification team must now take this into 
account, and possibly forward some stable cases to the 
Support/Maintenance team for careful backporting to stable. The rule is 
still the same about stable: only the Maintenance/Support team works on 
the stable branch.
Also please note that the bug policy templates on 
http://pad.openerp.com/bug-policy need to be reviewed before being used 
again!



B. We have also revised the policy regarding the handling of wishlists, 
and have updated the pad with instructions on 
http://pad.openerp.com/community-team-organization

The main change is that R&D teams will now ignore Wishlist bugs during 
sprints by default. The links on the pad have been updated, please be 
careful to use the new ones.

This also means that the bug qualification teams must now determine if a 
Wishlist/Improvement should be processed for the current release, for a 
future release, or never:

 - set Wishlist + Won't Fix if sure that this is something we don't 
want, e.g. functionally uninteresting, too much of a special case, etc.

 - set Wishlist + Confirmed + Assign Team when you think this is a good 
idea that could be considered in future release (to be prioritized later 
by R&D team leaders for including in future sprints)

 - set Low + Confirmed + Assign Team if this is a very low priority bug 
that you think needs to be fixed for the current release


Note: existing Confirmed Wishlist bugs will be reviewed to verify if 
they should be changed to Low to be included in current release


Thanks for applying the new policy and procedure, and do not hesitate to 
contact me of Jay if you have any question, or if this is not clear!