Bug 203179 - Allow closing bugs with Open dependson
Summary: Allow closing bugs with Open dependson
Status: In Progress
Alias: None
Product: Services
Classification: Unclassified
Component: Bug Tracker (show other bugs)
Version: unspecified
Hardware: Any Any
: --- Affects Only Me
Assignee: Kubilay Kocak
URL:
Keywords: needs-qa
Depends on:
Blocks:
 
Reported: 2015-09-17 19:10 UTC by Jan Beich
Modified: 2016-10-30 23:21 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Beich freebsd_committer 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 freebsd_committer freebsd_triage 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 freebsd_committer 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.