You have the following choices: This will cause all of the above changes to be overwritten. s/will/may/; s/all/some/ -- patch coming so i can test the silly attachment manager

Comment on attachment 48080 [details] [diff] [review] Change error message What's this?

Comment on attachment 48080 [details] [diff] [review] Change error message What's this?

Please justify this wording change. And produce a patch which contains only the change :-) Gerv

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 on attachment 48080 [details] [diff] [review] Change error message needs-work per comments + templatisation The only thing which we don't change are changes where you've made the same changes as the midair has (or where something was changed and then changed back) - I'm not sure if we want to change the wording.

Unloved bugs targetted for 2.18 but untouched since 9-15-2003 are being retargeted to 2.20 If you plan to act on one immediately, go ahead and pull it back to 2.18.

This bug has not been touched by its owner in over six months, even though it is targeted to 2.20, for which the freeze is 10 days away. Unsetting the target milestone, on the assumption that nobody is actually working on it or has any plans to soon. If you are the owner, and you plan to work on the bug, please give it a real target milestone. If you are the owner, and you do *not* plan to work on it, please reassign it to nobody@bugzilla.org or a .bugs component owner. If you are *anybody*, and you get this comment, and *you* plan to work on the bug, please reassign it to yourself if you have the ability.

(In reply to comment #6) > The only thing which we don't change are changes where you've made the same > changes as the midair has (or where something was changed and then changed > back) - I'm not sure if we want to change the wording. I'd like to see better wording of that description! :) Bug 303738 cites a specific instance of a change that doesn't get reverted by a mid-air collision: additions to a CC list.

The wording is still not clear. It needs to say for each available option: 1. If my comments will be retained or lost 2. If the other comments will be retained or lost.

Bug 303738 should be a dup of this bug, not a blocker. Apart from comments and CCs, there are more things that are not overwritten, e.g. additions to See Also. Instead of adding more exceptions to the collision message, - the message should be changed to something like this: "This will cause changes marked by [*] to be overwritten." - and a [*] should be added to the changes that will actually be overwritten.