This is a draft proposal by a contributor to the mozilla project and not an employee of any entity or agency. Bugzilla is capable of marking bugs as closed, this can be a useful feature, but it only makes sense if products ship. Currently Mozilla SeaMonkey has the position that it has never shipped so no Mozilla Seamonkey bugs should be closed. The situation. People occasionally elect to reopen an old bug which was fixed by a code change to CVS for the trunk and for which the code change was verified to fix the problem. The problem. If another fix is checked into cvs under the same bug number you now have multiple fixes in cvs for a bug and things get messy. Bugs also can morph to a point where they will never be closable but will be reopened. Proposal. 1. We change the definition of shipping Seamonkey (and whatever the next codename for the project - or not, if the mozilla2.0 project elects not to follow this proposal that's fine). 2. We define criteria which allow bugs to be closed 3. We define standards which prevent people from reopening closed bugs. Definition of shipping the Seamonkey product: the release of a milestone build on the major platforms. (this means that if Windows has a 0.9.2.1 and no other platform has such a release it will not count. Similarly if Mozilla MacOS had a 0.8.8 and there of course were no windows or linux 0.8.8s it would not count). Criteria to allow bugs to be closed: A. The bug is in a standard seamonkey component (Evangelism is explicitly excluded). B. The bug reached a proper resolution as Fixed. By a code change as Invalid. By someone in authority to make such a decision * this probably needs to be discussed The following resolutions are not covered by these criteria: Wontfix. Worksforme C. The bug was verified according to standard practices e.g. [Verifier!=Resolver] D. The bug has not had a significant comment during the interval between the shipping of 3 seamonkey product versions. this allows for QA contact updates or additional worksforme/verified comments and accidental comments. But excludes bugs where someone responded to a verify by saying that it didn't work for them. - Cases not handled: 1. Someone complains a bug isn't fixed w/in 2-3 shipped products of the verify. Expected reaction is activity by QA or Assignee. QA Contact or commenter could indicate in the bug that they have filed a new bug. This would mean that at a future product shipping the old bug could be closed 2. Worksforme/Invalid, I think that setting criteria D to indicate 5 versions w/o complain should be satisfactory. Rule against reopening closed bugs: If a bug is closed according to the practices indicated above (or as standardized in a future version..) then the bug should not be reopened. A new bug should be filed (or found) for any/all outstanding issues. QA or someone acting in that position should make use of an annotation field (e.g. Status White board) or dependency fields and the comment field to indicate the new bugs to monitor for the various unresolved issues. I chose 3/5 releases because they guarantee a reasonable amount of time between verifying and closing (to allow for a complaint/reopen) while preventing bugs from languishing forever as they do now. Other cases. In the event a bug is about a module or component which is totally rewritten there should probably be a way to close the bug, I think that the time intervals suggested here are sufficient.
