Closed
Bug 8527
Opened 25 years ago
Closed 13 years ago
Need an extension to reopen a sleeping bug when its dependencies are resolved
Categories
(Bugzilla :: Extensions, enhancement, P5)
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: ian, Unassigned)
References
Details
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.
Updated•25 years ago
|
Status: NEW → ASSIGNED
Comment 1•25 years ago
|
||
This does strike me as cool. Magic states are worrisome, because they're hard
to document and discover, but it does seem cool...
Reporter | ||
Comment 2•25 years ago
|
||
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.
Comment 3•25 years ago
|
||
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.
Comment 4•25 years ago
|
||
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 .)
Assignee: terry → tara
Status: ASSIGNED → NEW
Comment 5•25 years ago
|
||
this still sounds like a cool idea to me. what happened to it?
Updated•24 years ago
|
Summary: RFE: New resolution "DEPENDS" would be cool → RFE: New status "ASLEEP" would be cool
Comment 6•24 years ago
|
||
Yeah, this does sound cool. Updating summary to accurately reflect the current
direction of this bug.
Reporter | ||
Comment 7•24 years ago
|
||
Chris, you'll love this one!
BTW: A more mundane name for 'ASLEEP' has been suggested: 'BLOCKED'. Bah. ;-)
Assignee: tara → cyeh
Whiteboard: 2.12
I think we should drop this for 2.12 consideration and push it off for later.
Any comments?
Comment 9•24 years ago
|
||
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. :)
Comment 11•24 years ago
|
||
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.
Reporter | ||
Comment 12•24 years ago
|
||
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?)
QA Contact: py8ieh=bugzilla
Comment 13•24 years ago
|
||
> 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 = ""'.
Comment 14•24 years ago
|
||
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).
Comment 15•24 years ago
|
||
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.
Comment 18•23 years ago
|
||
New product: bugzilla.
Component: Bugzilla → Creating/Changing Bugs
Product: Webtools → Bugzilla
Version: other → 2.10
Updated•23 years ago
|
Whiteboard: [flow:status]
Comment 19•23 years ago
|
||
Fixing up assignee and QA ...
Assignee: justdave → ian
QA Contact: ian → matty
Comment 20•22 years ago
|
||
More generally speaking, manager-defined lists of Statusses and Resolutions
would be cool.
(I need RTFM and MISSING_DESCRIPTION.)
Comment 21•21 years ago
|
||
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?
Comment 22•21 years ago
|
||
go for it.
Updated•21 years ago
|
OS: other → All
Hardware: Other → All
Summary: RFE: New status "ASLEEP" would be cool → New status "ASLEEP" would be cool
Reporter | ||
Comment 23•21 years ago
|
||
Bailing on Bugzilla 3.0 due to too many other commitments.
Assignee: ian → nobody
Comment 24•20 years ago
|
||
*** Bug 254634 has been marked as a duplicate of this bug. ***
Comment 25•20 years ago
|
||
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?
Updated•20 years ago
|
Assignee: nobody → nobody
Updated•18 years ago
|
QA Contact: mattyt-bugzilla → default-qa
Updated•18 years ago
|
Depends on: bz-custstat
Priority: P3 → P4
Whiteboard: [flow:status] → [blocker will fix]
Target Milestone: Bugzilla 3.0 → ---
Comment 26•17 years ago
|
||
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.
Updated•17 years ago
|
Summary: New status "ASLEEP" would be cool → Need a plugin to reopen a sleeping bug when its dependencies are resolved
Updated•17 years ago
|
Whiteboard: [blocker will fix]
Updated•16 years ago
|
Assignee: nobody → create-and-change
Updated•16 years ago
|
Priority: P4 → P5
Summary: Need a plugin to reopen a sleeping bug when its dependencies are resolved → Need an extension to reopen a sleeping bug when its dependencies are resolved
Updated•15 years ago
|
Component: Creating/Changing Bugs → Extensions
Updated•15 years ago
|
Assignee: create-and-change → extensions
Comment 27•13 years ago
|
||
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
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•