At the moment there doesn't seem to be any way to prevent the following: Bug 1 [M11] depends on Bug 2 [M12]. A conservative way to handle this is to whine to both bug assignees about this.

And also providing warnings on process_bug when either bug is changed.

The original dependencies bug #6987 suggested the same for priorities. This would make sense too if done in this way.

We may need something even more flexible than that. At the moment, our rules are such that we need to also consider the status whiteboard contents (PDT+ bugs) and keywords (beta1, dogfood) to get the right level of whining. This could probably be specified as a boolean expression similar to those that can be built on the query page, so it may not be onerous to implement if that can be leveraged. These rules would be settable on a per-product basis by some sufficiently privileged user - right? For individual bugs, it looks like you could build a query that would return only bugs in violation - but only when depend attributes work and then only for a particular bug. Is there a fancy way to do this query against all bugs within a product that have dependencies? This would be a very helpful tool for managing the product as a whole. If the whine doesn't force a corrective action, then the query is actually required so managers can find these problems and force corrective action manually. (I suppose the forcefulness could also be an attribute associated by product.)

Keyword restrictions are discussed at 26940. Status whiteboards aren't really necessary as PDT should migrate to keywords. Anyway, the other bug allows keywords to be restricted to a specific product, which should provide what you are looking for. Assumedly PDT+ for Browser means the same as for MailNews from the perspective of this bug, so you don't want it product-by-product as such. Bear in mind that these restrictions are always going to apply to all products on all Bugzillas, whereas the keyword restrictions are defined by the keyword owner or maintainer for a specific Bugzilla, so they're slightly different. There might be other restrictions out there that are owned by the product owner on a product by product basis, but I can't think of any offhand. I don't think there's any way to ask whether a restriction applies to all dependents or all dependees like an advanced query to do this manually would need to do. It would be nice. A page showing bugs that need attention would definitely be worthwhile, I'm not sure whether it could be a query unless we add a specific advanced query condition for broken bugs, since the number of restrictions is open-ended in general. A query condition would not be a bad idea I think. However if you restrict it to just priority/milestone ordering, then you could do without if you had the dependent querying facility.

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 .)

3.0: This would be a handy diagnostic tool to assignees in their targetting.

See also bug #40666 for the milestone bit.

moving to real milestones...

This should also whine if any open bugs have a milestone older than the current milestone.

That's bug #65388.

Moving to new Bugzilla product ...

Changing default owner of Email Notifications component to JayPee, a.k.a. J. Paul Reed (preed@sigkill.com). Jake will be offline for a few months.

Now that bug 185090 has landed, it becomes easy to generate various reports, except that the search system doesn't have a way to search on dependency milestones. Adding dependency on bug 252461, which is likely to wind up including that.

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

This bug has nothing to do with "Whining" This bug is about preventing dependent bugs from having illogical relationships.

Bugzilla 3.2 is now frozen. Only enhancements blocking 3.2 or specifically approved for 3.2 may be checked in to the 3.2 branch. If you would like to nominate your enhancement for Bugzilla 3.2, set the "blocking3.2" flag to "?". Then, either the target milestone will be changed back, or the blocking3.2 flag will be granted, if we will accept this enhancement for Bugzilla 3.2. This particular bug has not been touched in over eight months, and thus is being retargeted to "---" instead of "Bugzilla 4.0". If you believe this is a mistake, feel free to retarget it to Bugzilla 4.0.

That's not something we want to implement as it should be more a social thing than enforced by a technical policy. It totally makes sense to have a bug depending on another bug targetted to a later milestone. For instance, a bug in the Bugzilla product targetted 4.2 may be fixed on trunk by a bug targetted 4.4, and on 4.2 by a less invasive fix (this just happened to us this week). It doesn't make sense to enforce this in the core code. When this bug was filed, I'm pretty sure you didn't have branches in mind, and this RFE is not compatible with multiple branches.