Today there was a mid-air collision on bmo bug 395850. The first person changed the assignee, component, and QA contact. His change to the assignee was a mistake, accidental. The second person (me) changed the component, QA contact, status and summary but not the assignee. Both persons changed the component and QA contact to the same new value, so in truth, there was no conflict on the component or QA contact. The conflict was on the assignee. The attempt to commit the second change reported a mid-air collision, and reported that the collision affected the assignee, component and QA contact. It offered two choices, one of which was to "go ahead and make my changes anyway". It claimed that this choice would discard all the first party's changes, except the comment. I chose this choice. I intended that the effect would be that the assignee would be restored to the value that it was before either of us tried to change this bug. By discarding the first party's changes, and taking mine, it would change the assignee back to the original (correct value), and leave the component and QA contact with the correct new values that both parties had chosen. But committing the second change actually did not discard/undo the first person's change to the assignee. It kept the first person's change to the assignee, and discarded my choice of assignee. It did not do what the page said that choice would do. That's the bug. The mid-air conflict page should accurately describe what the "go ahead and make my change, discarding the previous change" choice really will do. That choice should do exactly what the conflict page says it will do.
Bug 107306 is the bug everyone points to when you point out a problem with the midair messages!
Bug 107306 seems like a major overhaul. One might even call it "blue sky". I'm not asking for a major item-by-item decision feature. I just want the all-or-nothing feature to be what it claims to be: all or nothing. Mostly it must do what it says it will do, and it must say it will do what it actually will do. Right now, it says "make my changes anyway" will discard all shown changes except comments. Evidently, the truth is, it will discard all shown changes except comments AND Assignee changes. If that's how it works, then it should say that.
(In reply to comment #2) > Bug 107306 seems like a major overhaul. One might even call it "blue sky". > I'm not asking for a major item-by-item decision feature. > I just want the all-or-nothing feature to be what it claims to be: > all or nothing. Understood. I'm just noting that other bugs that have been filed about problems with the midair page usually have comments from Bugzilla developers that just point to that bug and say "this will be resolved when that is".
I wouldn't say this is major--it never did what it says. :-) It only overwrites their changes with your changes. So if you didn't modify one of the fields they modified, it won't be overwritten. Really, we just need a better message there. Feel free to suggest one.
Severity: major → minor
Definitely not minor with bugzilla misleading users, leaving users with no good idea what to expect from collision resolution. At this point, I just don't know what to expect from mid-air collision resolution any more. I just know not to expect that it will do what it says it will do. It bothers me that bugzilla developers seem unconcerned.
Severity: minor → normal
Sorry but this is not a bug in Bugzilla. When you reassign a bug on b.m.o, the assignee field is automatically reset to the default assignee of the component, who is firstname.lastname@example.org in NSS/Build. As you also changed the component field, the assignee field has also been set to email@example.com and so didn't overwrite the already set assignee field. The "automatically reset the assignee" behavior when changing the component is specific to b.m.o and is not implemented upstream (just in case you wanted to complain to core Bugzilla devs).
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → INVALID
Frederic, It is true that BMO sets the default action to reassign when you change the component, but I changed it back, to leave the bug assigned to the present assignee. So you analysis does not apply to what happened here.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
You mean you selected "Leave as..."?
yes. The bug was assigned to Alexei (correct assignee) and was in state assigned, but was in component test, which was wrong, the correct component is build. Alexei and I both attempted, in parallel, and without knowing what the other was doing, to change the component to build. When Alexei changed the component, he did not notice that the page selected the "reassign to default assignee" action, so when he committed, his commit changed the assignee to nobody, which was unintentional. But that is NOT the problem that is the subject of this bug. I made a similar change. I started from the same state as Alexei did, where the bug was in "assigned" state, assigned to Alexei, but I knew that the page would try to change the assignee, so I explicitly checked "leave as assigned" action. I also changed the QA contact to be the right one for that component. When I committed, the page told me that there were 3 conflicts: Assignee: Alexei (my choice) vs nobody (Alexei's change) Component: Build vs Build, the same in both cases, not really a conflict at all in my opinion, but it was reported. QA contact: firstname.lastname@example.org vs email@example.com, the same in both cases. The choices were: throw away my changes, or keep my changes and throw away Alexei's (except his comment). The only differences were (or should have been) the assignee and the state. My intent was to restore the bug to be assigned to Alexei and to assigned state. But that's not what happened.
It appears to me that the addition of a comment, when that is the only change being made, CANNOT (by itself) be a "collision". When I add a comment (only, no other change), and get a collision page, it seems I can ALWAYS safely just click "Take my changes anyway and throw away any other changes" (or whatever it says) without any fear that I'm actually undoing any changes that anyone else has made. Assuming that's true, then no "collision" page should be presented to me in such a case. If my changes cannot possibly undo anyone else's, then they should simply go right in, without any collision page report. I think that the VAST majority of collision pages I get are bogus. They tell me that if I go ahead, I will undo changes that I KNOW FOR A FACT will NOT be undone by the mere addition of my comment. It's getting to the point where I'm not very incented to even look at collision pages seriously any more. A least 90% of the time, I've just added a comment, and so now I've learned to just "click through" them. If that seems undesirable, then bugzilla need to change to a state where the warning pages have a higher than 1% probability of actually representing a real collision. Now, they're just crying Wolf!
Summary: mid-air collision resolution doesn't do what it says → mid-air collision pages cry wolf
The behavior of bugzilla has changed since I wrote comment 10. Today I added a long comment to bug 259996. Adding the comment was the only change I (intentionally) made to the bug. While I was typing it in, someone else changed the bug's QA contact. When I submitted the comment, I got a mid-air collision page, telling me that if I submitted my comment, all the changes would be undone. Based on my past experience with this (as documented in the above comments in this bug) I went ahead and submitted my comment anyway, believing that bugzilla would NOT actually undo those changes, that bugzilla was still merely "crying wolf" as it had done so many times in the past. But this time, to my surprise, it did what the mid-air collision page said it would do. It did undo the change to the QA contact, setting it back to the old value that the bug had when I started entering my comment. So, then I immediately made another change, re-applying the QA contact change that I had undone. I gather that sometime between July 2008 and now (December 2009) bugzilla has been changed, so that it now really is "all or nothing", just like the mid-air collision page has always said it was. But whoever fixed it didn't resolve this bug as fixed. So, I'd like to ask if anyone knows what change had that effect. Can anyone cite the bug whose patch effected the fix for this bug?
Status: REOPENED → NEW
(In reply to comment #11) > So, I'd like to ask if anyone knows what change had that effect. Can anyone > cite the bug whose patch effected the fix for this bug? There has been a lot of rewrite/refactoring of process_bug.cgi since Bugzilla 3.0. There isn't one specific bug which fixed this problem. It's rather the whole process which did the job.
Status: NEW → RESOLVED
Closed: 12 years ago → 8 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.