73173 - Ability to specify comment as explanatory

Status: RESOLVED DUPLICATE of bug 105597

(Bugzilla :: Creating/Changing Bugs, enhancement, P3)

Description

[Matthew Tuck [:CodeMachine]]

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.

Comment 1

[Matthew Tuck [:CodeMachine]]

... but only if they actually make a change ...

Comment 2

[Matthew Tuck [:CodeMachine]]

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.

Comment 3

[Christopher Aillon (sabbatical, not receiving bugmail)]

->New (old by now?) product Bugzilla 

Comment 4

[Matthew Tuck [:CodeMachine]]

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?

Comment 5

[Dave Miller [:justdave]]

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.

Comment 6

[Stephen Rasku]

Is this really necessary?  If people are making unnecessary comments what makes
you think that they will click on the check box.

Comment 7

[Matthew Tuck [:CodeMachine]]

This is not about unnecessary comments.

Comment 8

[Stephen Rasku]

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.

Comment 9

[Matthew Tuck [:CodeMachine]]

People who make changes to bugs are typically fairly experienced with the bug
system.  They would know to.  I think they would remember.

Comment 10

[Matthew T (active 1999-2002)]

I think this would be more cluttersome+confusing than useful.

Comment 11

[Dave Miller [:justdave]]

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)

Comment 12

[Dave Miller [:justdave]]

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.

Comment 13

[Shane H. W. Travis]

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 ***

Comment 14

[Shane H. W. Travis]

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 ***