|Summary:||Allow closing bugs with Open dependson|
|Product:||Services||Reporter:||Jan Beich <jbeich>|
|Component:||Bug Tracker||Assignee:||Kubilay Kocak <koobs>|
|Status:||In Progress ---|
|Severity:||Affects Only Me||CC:||bugmeister|
Description Jan Beich 2015-09-17 19:10:24 UTC
Sometimes blocked bugs can land independently from their dependson field. This may happen if the actual dependency isn't hard but advisory in nature or if the fix needs more work. See bug 196978 comment 13 or bug 202642 comment 7 for examples. bugzilla.mozilla.org has no such limitation.
Comment 1 Kubilay Kocak 2015-11-02 06:45:28 UTC
The ability to change this is an existing administrative setting: noresolveonopenblockers Don't allow bugs to be resolved as fixed if they have unresolved dependencies. The current setting is ON. The intended reason for this is so that dependent issues are not orphaned, and so users unintentionally closing blocked issues are notified. I am very tempted to argue that if a issue isn't "actually" a dependency, then the Blocks/Depends On fields should not be used. Bugzilla has a "See Also:" field which can contain multiple references to issues within the local issue tracker, and supports remote references for a number of other issue tracker products. This can be used to express a loose notion of 'related issues'. I think a better sense/definition of what kind of 'dependency' is attempting to be expressed is needed before any potential or actual solutions are evaluated. It's also worth noting the distinction between: 1) Changes can be committed independently, and 2) Issues can be resolved independently The issue tracker does not actually constraint (1) at all, just 'resolution'.
Comment 2 Jan Beich 2016-10-30 23:21:42 UTC
(I don't remember why this was sitting in my drafts/ folder) (In reply to Kubilay Kocak from comment #1) > I am very tempted to argue that if a issue isn't "actually" a > dependency, then the Blocks/Depends On fields should not be used. What's a dependency? Something that relies on the other. However, such relationship maybe dual. For one, in bug 196678 case reporter confused runtime vs. build i.e., X11 drivers depend on xorg-server API but xorg-server may have its own rules how to autoplug specific X11 drivers. Another case is if a bug landed causing a regression but it's not critical enough to back out. Or if a patch depends on another but if landed before would be nop. > Bugzilla has a "See Also:" field which can contain multiple > references to issues within the local issue tracker... It's not a defined meaning. People may treat the values differently similar to Status field (e.g. bug 203471 comment 4). See Also This allows you to refer to bugs in other installations. You can enter a URL to a bug in the 'Add Bug URLs' field to note that that bug is related to this one. You can enter multiple URLs at once by separating them with a comma. You should normally use this field to refer to bugs in other installations. For bugs in this installation, it is better to use the Depends on and Blocks fields. I can only imagine putting examples there, e.g. those in comment 0. Note, [meta] bugs usually means something else. > The intended reason for this is so that dependent issues are not orphaned, and so users unintentionally closing blocked issues are notified. Did you check Bugzilla notification defaults? Bugs filed as regressions against Closed can still be orphaned. And hard dependencies are easy to notice via build breakage. https://bugs.freebsd.org/bugzilla/userprefs.cgi?tab=email I want to receive mail when: [x] The dependency tree changes which leads to Subject: [Bug N] Add foo/bar Bug N depends on bug M, which changed state. Bug M Summary: blah blah What |Removed |Added ---------------------------------------------------------------------------- Status|New |Closed Resolution|--- |FIXED Referenced Bugs: [Bug M] blah blah > It's also worth noting the distinction between: > > 1) Changes can be committed independently, and > 2) Issues can be resolved independently Closed->FIXED already tells me enough as a TODO item (after triage) where Assignee defines when (1) transcends into (2). FIXED A fix for this bug is checked into the tree and tested > The issue tracker does not actually constraint (1) at all, just 'resolution'. Agree but some trackers blur the distinction via close-by-commit.