openerp-dev-web team mailing list archive

[Xavier Morel <xmo@xxxxxxxxxxx>]

The process, as outlined in http://pad.openerp.com/rd-v61-process, is the following:

• In a branch called <trunk-bug-$bugnumber-$author> use the command:
• make branch-trunk-bug
• Set status to "in progress"
• Work on bug (commit with --fixes)
• Make the merge proposal on trunk
• Review by indian team leader on the merge proposal page
• Once the indian team leader approve the merge proposal, ask for the belgian review and set status to "Fix Commited"
• Merge to trunk by belgian contact, set status to "Fix released"

I'd like to note one thing: a bug is *not* fixed when reaching the previous-to-last step. We're using the "Fix Commited" status to indicate that a fix has been *proposed* and is under review, this does not mean the fix is complete, this does not mean the fix is complete and this does not mean the proposed fix will ever be merged.

As a result, I don't think it's correct to claim that the bug has been fixed, even in an other branch, as is currently done, when switching status to "Fix Committed". Because that's not true.

Indicating that a potential fix has been proposed would be OK, providing a link to the runbot branch so the reporter (and other people having noticed the bug) would be even better, if neither is done I think it would be better to not comment at all rather than to lie.

Also, don't use revision numbers to identify revisions, they're not stable, please use revision ids (the string which starts with the user's identifier and looks like puke)