While we wait for an official bugzilla release that supports regressions as well as dependencies (see bug 251556), It would be helpful if in the BMO instance of bugzilla, the field titles were changed in the following manner: From To Depends on Depends on (or Regresses) Blocks Blocks (or Regressed by)

How about at least "Caused" and "Caused by" instead of "Regresses" and "Regressed by"?

(In reply to comment #1) > How about at least "Caused" and "Caused by" instead of "Regresses" and > "Regressed by"? > Even better!

I think this is a good idea.

Not really a good idea as not all projects use the same definition of depends on and blocks. e.g. Bugzilla uses it the other way.

Why does Bugzilla do it the other way? I think we should try to be consistent, and modifying the description of the field on b.m.o would help with that. Would it be hard for the Bugzilla project to switch?

(In reply to comment #5) > Why does Bugzilla do it the other way? Because we always did it this way. For us, a regression depends on an already committed patch, not the opposite. For the story, the way you do it would be incompatible with the 'noresolveonopenblockers' parameter which prevents a bug from being resolved if it still has open blockers. But I know you don't care as this param is off on b.m.o. :) > Would > it be hard for the Bugzilla project to switch? We are not going to switch existing dependencies; this wouldn't make sense and would generate a lot of bugspam. And mixing both the old and new rules may lead to dependency loops. As this is a hack for b.m.o only, why not hacking the template to not display these new labels when displaying a Bugzilla bug?

The real solution here would be having four fields instead of two (bug 251556) -- that would also prevent the dependency loop prohibition from being triggered in real cases.

If you are using the same 2 fields to show dependencies for fixing a bug and to show regression causes, then the way Mozilla is using the fields is the one and only correct way to do so. The other way defies logic. We all agree that for fixing a bug if you must fix bug a to resolve bug b, then bug b is dependent on bug a. In fact resolving bug q might just resolve bug b in and of itself. Now breaks is the opposite of fix. So if this is the correct dependency for the case where bug a fixes by bug a, then the opposite dependency must be correct for the case when bug a causes bug b. But that is really all irrelevant here. I am not asking for a change in the Bugzilla product, just in the BMO implementation of it. This is merely a change in the labels used on the various pages it displays. This should just be a localization string change.

(In reply to comment #8) > But that is really all irrelevant here. I am not asking for a change in the > Bugzilla product, just in the BMO implementation of it. Frédéric is pointing out that the Bugzilla project uses BMO to track it's bugs, and that this proposed change would be incorrect because their convention is to do the opposite of what the Core/Firefox/Other products do (i.e., put the bugs that caused the regression in "depends on"). (In reply to comment #6) > As this is a hack for b.m.o only, why not hacking the template to not display > these new labels when displaying a Bugzilla bug? I suppose that would work.

Oh I see. I somehow missed that. I thought he was talking about other Bugzilla instances. That makes the change more complicated. I was hoping it could all be done via changing localizable strings.

Rearranging this component to not have me as the default assignee, so that it doesn't appear like I'm intending to work on bugs that other people could be taking care of if they didn't think I was already doing them. If this bug is a software issue on b.m.o and you'd like to fix it, the modified source is now available for the patching (see bug 373688). Reassigning to the new default owner.

In the meantime bugzilla upstream added support for additional bug relationship fields. Rather than try to rework and overload the dependency fields as described here we should turn on the new feature instead (now that we've upgraded BMO to a new enough version). That request is in bug 490926 and I propose this bug be either WONTFIXED (as written) or duped to that bug as effectively equivalent.