395970 - mid-air collision pages cry wolf

Status: RESOLVED WORKSFORME

Description

[Nelson Bolyard (seldom reads bugmail)]

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.

Comment 1

[:Gavin Sharp [email: [e-mail]]]

Bug 107306 is the bug everyone points to when you point out a problem with the midair messages!

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

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.  

Comment 3

[:Gavin Sharp [email: [e-mail]]]

(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".

Comment 4

[Max Kanat-Alexander]

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.

Comment 5

[Nelson Bolyard (seldom reads bugmail)]

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.

Comment 6

[Frédéric Buclin]

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 [e-mail] in NSS/Build. As you also changed the component field, the assignee field has also been set to [e-mail] 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).

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

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.

Comment 8

[Frédéric Buclin]

You mean you selected "Leave as..."?

Comment 9

[Nelson Bolyard (seldom reads bugmail)]

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: [e-mail] vs [e-mail], 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.

Comment 10

[Nelson Bolyard (seldom reads bugmail)]

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!

Comment 11

[Nelson Bolyard (seldom reads bugmail)]

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?

Comment 12

[Frédéric Buclin]

(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.