With the new email filtering, there are some problems. Most people would want general comments on, but specific changes off. Yet, many changes come along with comments, but the comment only explains the change. By this, I don't mean crud like "-> M13", I mean something useful like "moving to M13 as ...", which actually has some use. But these explanations will result in people receiving the change who don't want to. What I propose is that on show_bug.cgi we include a checkbox that says "Comment is purely explanatory of changes.". In this case, we don't class it as having a comment for email filtering purposes. We might change the email filtering to say "Receive Not Purely Explanatory Comments". Another benefit, is that for a mass change, if certain bugs have no actual changes to make because their current values are already correct, we don't have to add a comment and submit notifications.
Summary: Ability to specify comment as explanatory. → Ability to specify comment as explanatory
Version: other → Bugzilla 2.12
... but only if they actually make a change ...
We should include explanatory-status in the longdescs table. Later we may wish to not show these comments on a view that doesn't show the change. See bug #11368 for background.
->New (old by now?) product Bugzilla
Assignee: tara → myk
Component: Bugzilla → Creating/Changing Bugs
Product: Webtools → Bugzilla
Version: Bugzilla 2.12 → 2.12
I think a good interface on show_bug.cgi is to have a checkbox under the comment that says 'People who don't care about my change won't care about my comment.'. That makes it fairly easy to understand I hope. mpt, any comments?
We are currently trying to wrap up Bugzilla 2.16. We are now close enough to release time that anything that wasn't already ranked at P1 isn't going to make the cut. Thus this is being retargetted at 2.18. If you strongly disagree with this retargetting, please comment, however, be aware that we only have about 2 weeks left to review and test anything at this point, and we intend to devote this time to the remaining bugs that were designated as release blockers.
Target Milestone: Bugzilla 2.16 → Bugzilla 2.18
Is this really necessary? If people are making unnecessary comments what makes you think that they will click on the check box.
This is not about unnecessary comments.
That's not my point either. My point is that only a small portion of people making "explanatory comments" will bother to check the box.
People who make changes to bugs are typically fairly experienced with the bug system. They would know to. I think they would remember.
I think this would be more cluttersome+confusing than useful.
Enhancements which don't currently have patches on them which are targetted at 2.18 are being retargetted to 2.20 because we're about to freeze for 2.18. Consideration will be taken for moving items back to 2.18 on a case-by-case basis (but is unlikely for enhancements)
Target Milestone: Bugzilla 2.18 → Bugzilla 2.20
Bugzilla 2.20 feature set is now frozen as of 15 Sept 2004. Anything flagged enhancement that hasn't already landed is being pushed out. If this bug is otherwise ready to land, we'll handle it on a case-by-case basis, please set the blocking2.20 flag to '?' if you think it qualifies.
Target Milestone: Bugzilla 2.20 → Bugzilla 2.22
This is a subset of the later, larger, more useful change described in Bug 123304, so I'm marking it as a duplicate of that. *** This bug has been marked as a duplicate of 123304 ***
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → DUPLICATE
Target Milestone: Bugzilla 2.22 → ---
bug 123304 is a duplicate of bug 105597, so duping them both to the same one. *** This bug has been marked as a duplicate of 105597 ***
Status: REOPENED → RESOLVED
Last Resolved: 14 years ago → 14 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.