Closed
Bug 395970
Opened 18 years ago
Closed 14 years ago
mid-air collision pages cry wolf
Categories
(Bugzilla :: Creating/Changing Bugs, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: nelson, Unassigned)
Details
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•18 years ago
|
||
Bug 107306 is the bug everyone points to when you point out a problem with the midair messages!
Reporter | ||
Comment 2•18 years ago
|
||
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•18 years ago
|
||
(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•18 years ago
|
||
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
Reporter | ||
Comment 5•18 years ago
|
||
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
![]() |
||
Comment 6•18 years ago
|
||
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 nobody@nss.bugs in NSS/Build. As you also changed the component field, the assignee field has also been set to nobody@nss.bugs 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: 18 years ago
Resolution: --- → INVALID
Reporter | ||
Comment 7•18 years ago
|
||
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 → ---
![]() |
||
Comment 8•18 years ago
|
||
You mean you selected "Leave as..."?
Reporter | ||
Comment 9•18 years ago
|
||
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: build@nss.bugs vs build@nss.bugs, 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.
Reporter | ||
Comment 10•17 years ago
|
||
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
Reporter | ||
Comment 11•15 years ago
|
||
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
![]() |
||
Comment 12•14 years ago
|
||
(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: 18 years ago → 14 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•