Comment 4 for bug 887875

Agreed with Sebastien that locking is a good thing. The types of bugs that get improperly re-opened tend to have lots of comments and activity, so as a developer when you hit a bug that's been incorrectly reopened it takes several minutes of study before you realize what's going on - time that would have been better spent on a real bug. I agree with seb that for many reasons even if it is the same bug, it's often better to have a clean new report to work from in these cases.

I don't think we should have another knob to have to turn to lock a fixed bug. In Ubuntu a lot of bugs get set to Fix Released automatically via the changelog, and so that would need to be made to always lock (thus risking unreasonable locks), or always unlock (leaving us back at the original problem of incorrect re-opens).

A few other ideas for solving this:

  * A 'Nominate to reopen' function analogous to series nominations. Perhaps re-open once a nomination is seconded by someone else

  * Per-project setting of which states are 'auto-locked', so bzr can have it one way and ubuntu another

  * Allow bugs to be reopened but denote them in some fashion so it's more evident to triagers/developers it's a re-open

  * Have the user file a NEW bug, but establish a link / relationship to the closed bug they think this is a regression of