reproducible. A bug can and should stay open as long as it is
still a bug and no one has fixed it. The following is a
suggested checklist to follow for handling these bugs, along with
- example replies. The various closings, taggings, etc, are done
+ example replies. Closing, tagging, etc., are done
with debbugs control messages, which in debbugs-gnu is initiated
with a "C".
[ ] Read the mail thread for the bug. Find out if anyone has
weeks, I'll just close this bug as unreproducible."
[ ] Check that the priority is reasonable. Most bugs should be
marked as normal, but crashers and security issues can be
- marked as "severe".
+ marked as serious.
4. Your changes will take some time to take effect. After a period of minutes
to hours, you will get a mail telling you the control message has been
processed. At this point, if there were no errors detected, you and
reproduce on the latest version, and if it can't be reproduced, ask the
reporter to try again with the latest version.
3. Is the bug the same as another bug? If so, merge the bugs.
- 4. What is the priority of the bug? Add a priority: critical, grave, serious,
- important, normal, minor, or wishlist.
+ 4. What is the priority of the bug? Add a priority: serious, important,
+ normal, minor, or wishlist.
5. Who should be the owner? This depends on what component the bug is part
of. You can look at the admin/MAINTAINERS file (then you can just search
emacs-devel to match the name with an email address).
+
+In the debbugs-gnu buffer, bugs are marked in the "State" column
+according to the communication flow. Red bugs mean that nobody has
+answered, these bugs need primary attention. Green bugs flag that
+there is a recent communication about, and orange bugs flag that the
+bug hasn't been touched for at least two weeks.