Now that Bugzilla supports the really cool dependency stuff, it would be useful if a bug could be resolved as DEPENDS. This resolution would remain until such time as all bugs that the bug in question depended upon had resolutions of their own (whether FIXED, INVALID, DUPLICATE or whatever), at which time the bug would magically REOPEN itself. This would be useful because it is really annoying to have bugs which lie in a bug list, when there is nothing you can do about them because they depend on some other bug being fixed. This would allow you to effectively mark the bugs as LATER, thus removing them from sight, but with the added bonus that once the dependencies are fixed, the bug reappears automatically.

This does strike me as cool. Magic states are worrisome, because they're hard to document and discover, but it does seem cool...

Ok, so I was sitting in the bus with nothing to do, and I came up with some more thoughts on this: Along with all the other options above the [Commit] button, there should be a new option for all bugs that are NEW, ASSIGNED, or REOPENED and have some bugs in the "Bugs that bug #### depends on" field: ( ) Send bug to sleep until all dependencies are resolved. The STATUS of the bug would then change to ASLEEP. When "checking for dependency changes", you would then look to see if any bug marked ASLEEP still has bugs that are NEW, ASSIGNED, or REOPENED. If an ASLEEP bug has _no_ such bugs, then it would have its status changed to REOPENED. Note: Loops would not be a problem using the above scheme, since if an ASLEEP bug depended on another ASLEEP bug, then it would reopen itself. That is to say, you can't, using the system described above, get bugs that drop out of the system completely. Note: I think it would be better to use a new STATUS rather than a new RESOLUTION as I had previously suggested.

Yes, that all sounds cool too. I don't see how loops are ever a problem. You can't set up dependency loops; there is already code to prevent that. I see no problem in letting an ASLEEP bug depend on another ASLEEP bug.

tara@tequilarista.org is the new owner of Bugzilla and Bonsai. (For details, see my posting in netscape.public.mozilla.webtools, news://news.mozilla.org/38F5D90D.F40E8C1A%40geocast.com .)

this still sounds like a cool idea to me. what happened to it?

Yeah, this does sound cool. Updating summary to accurately reflect the current direction of this bug.

Chris, you'll love this one! BTW: A more mundane name for 'ASLEEP' has been suggested: 'BLOCKED'. Bah. ;-)

I think we should drop this for 2.12 consideration and push it off for later. Any comments?

no argument from me. It'd be a cool tool, but it is a new feature, and a minorly complicated one at that. Let's nail the major bugs first. :)

dropping 2.12 from whiteboard, consideration for later.

Allow me to be the lone dissenting voice. I don't see why there's a need for this. Not only does it mean you can't tell whether a bug is UNCONFIRMED, NEW or ASSIGNED, and the info would be lost, if you don't want to see blocked bugs, you should just remove them from your queries. To be sure, querying on dependency is currently broken (bug #30823), but I think it should be fixed rather than doing this.

cyeh: sure that's fine -- just wanted to get this on to your radar. Matthew: yes, it does lose that information. Do we care? (I mean that in a curious way, not a sarcastic way.) If a bug is BLOCKED, then it is probably not UNCONFIRMED, since it depends on things already. You lose NEW/REOPENED, but then you lose those anyway when you resolve or accept, so that's not an issue. You lose ASSIGNED, but then if a bug is sleeping then it should probably be reevaluated when it resurfaces anyway. If we *do* care, then we can always save that information somewhere. The idea of this feature is that it would NOTIFY you when all dependencies are resolved. I don't see any way of doing that. This also allows me to see at a glance how many of my open bugs are blocked. I don't know any way of doing that. This bug is *not* about "getting bugs of my radar" necessarily, although it does make that possible. (And how would you do that now?)

> If a bug is BLOCKED, then it is probably not UNCONFIRMED, since it depends > on things already. What you describe is a simple way to confirm your bug then - just add a dependency. Not sure if this would be considered a major problem. > You lose NEW/REOPENED, but then you lose those anyway when you > resolve or accept, so that's not an issue. That doesn't concern me, I don't like REOPENED anyway. > You lose ASSIGNED, but then if a bug is sleeping then it should > probably be reevaluated when it resurfaces anyway. Why does it need to be reevaluated. You said you already get notified when it reopens, so surely you can choose. I'd say you'd want to keep it assigned more often than you'd want to unassign it. > The idea of this feature is that it would NOTIFY you when all dependencies > are resolved. I don't see any way of doing that. You don't need to add a status to add a feature to do that. > This bug is *not* about "getting bugs of my radar" necessarily, although it > does make that possible. (And how would you do that now?) You should be able to do that with an advanced query condition 'BugsThisDependsOn = ""'.

Explain to me how you query on the status of a bug that depends on the one that's the potential hit? I can query fine on whether or not a bug has dependencies. If you can tell me how to query on whether or not a bug has *unresolved* dependencies, maybe I'll be happy. I don't think you can do that. The idea of this one was to allow you to take a bug off your ASSIGNED list and have it show up again (and notify you) once the dependencies are resolved. You can kind of do this now with REMIND or LATER, but those also change the status to RESOLVED (which isn't good) and you would have to go back and manually reopen the bug after you're notified that the last dependency has been resolved. I'm in favor of the proposed status. I think it'll make more sense to call it "BLOCKED" than "ASLEEP" (as someone else suggested above). I don't think it should be automatic. I think the owner should have to move it to BLOCKED status manually (that way it doesn't take tracking bugs off the radar).

Chris, if this is still on the radar could you please target it or else I'll move it to BZ3 as I think Hixie has it planned.

retargetting for bz3

Taking all of cyeh's Bugzilla bugs.

New product: bugzilla.

Fixing up assignee and QA ...

More generally speaking, manager-defined lists of Statusses and Resolutions would be cool. (I need RTFM and MISSING_DESCRIPTION.)

What is the status of this bug? If I have time and if it's not extremely complex, I may take the project. Does the QA Contact have any input on this?

go for it.

Bailing on Bugzilla 3.0 due to too many other commitments.

*** Bug 254634 has been marked as a duplicate of this bug. ***

An interesting idea. Not automatically making bugs ASLEEP when they have dependencies is sensible, as (a) there may be work on the bug that can be done before dependencies are dealt with (b) it makes little sense to call a tracker bug asleep. But should a bug sleep till all dependencies are resolved? Or until one is resolved, in case it leads to more work on the bug?

OK, so we now have custom statuses implemented in 3.1+... meaning we could in theory just create this state on an install that wanted it. The only thing lacking would be a way to automatically reopen a bug when its dependency was resolved. Given that we don't want to add lots of statuses upstream, and want to avoid having special code, probably the best solution for this at this point it to write a plugin which hooks bug_status changes that does the reopening part. Then anyone who wants to add this state with this functionality can install the plugin to get the functionality part.

Hooks are in place to do this, AFAIK. This is not a feature which will be implemented in the core code. So someone wanting it should write an extension and add it to https://wiki.mozilla.org/Bugzilla:Addons#Bugzilla_Extensions