It would be nice if keywords could be defined to have restrictions. Examples could be along the lines of: beta1 : milestone < m15 css1 : component = Style System This could help ensure keywords are used properly and are removed when they no longer apply. If a keyword is added and the restriction fails, the change should be refused and the changer should go back and fix it. If changes made break a restriction where a keyword already present, the change should again be refused. If changes made result in a restriction that didn't previously hold still not holding, a warning should be issued on the process bug screen. This is for legacy/transitional purposes since the person making the change might not be the one in a position to fix the restrictions. There could also be some whining emails sent by a periodic agent that checks for these as well. I don't particularly care about the interface for defining the restrictions, but if there was a web capability, the query screen selection could be used.

Restrictions could apply to dependents, dependees or the current bug. For example, if there was a PDT+ keyword, you'd want it restricted to when all the bugs it depends on are also PDT+. This could partially help the situation where people shift things out which people are blocked on without realising it.

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

I think this is becoming increasingly important as the number of keywords in bugzilla.mozilla.org. People are becomingly increasingly reluctant to add keywords. I believe the primary reason is that it's hard to learn them all. If we had this we could separate them out: Component = Style System ------------------------ ... Milestone <= M15 ---------------- ... the ones that are currently applicable to this bug report would appear at the top, and the ones with the same restrictions would be grouped, making it easier to see which are applicable!

3.0: This should at least be considered from a schema POV.

beta1 should apply regardless of the target milestone, since it is a nomination keyword, and any bug can be nominated, whatever the current target. css1 should apply regardless of the component, in fact many CSS bugs are Layout bugs and not Style System bugs.

beta1 => beta1+ component => product

Moving to real milestones...

Taking all Bugzilla 3.0 bugs -- congratulations to MattyT for the triage, it really was spot on. Note: I may end up pushing some of these bugs back to 3.2, we'll see. However, I believe all these bugs should just fall out of the redesign. Let's hope I'm right! (Note: I'm also resetting the priority field to "---" so that I can retriage any that I consider important or likely to be dropped.)

The Bugzilla 3 component is going away. We're going to depend on the Milestones for this. At the time this component was created, we didn't have milestones for Bugzilla.

would love to see this for use in Tech Evang as we are using lots of stuff in the status whiteboard that we would love to use keywords for.

Taking this back to 2.18. This shouldn't be too hard to code and will make tech evangelism work much easier. To start off, this could be configured by a text configuration file or something in localconfig that would look like: keyword -> condition condition could contain one of the following magic strings which would apply to a bug: targetmilestone component product severity resoultion (other things could be added here, this is just a rough braindump) attributes like >, <, =~, eq, or ne would be follow the magic string var. Whenever a bug is changed, any conditions attached are examined to see if they are still met and if not an error is raised. There is lots of potential for this, but taking it a step further, one could attach conditions to individual bugs. For example, a meta bug of release blockers could be setup that only asa and add dependancies to. The condition could be written like: changer ne 'asa@mozilla.org' && action eq 'adddep' While this would take some work to impliment, I am willing to help with this. The first thing to do would be to write a module to parse and evaluate the conditions. Once that is done, all that has to be done is hooking it up to a UI.

Enhancements which don't currently have patches on them which are targetted at 2.18 are being retargetted to 2.20 because we're about to freeze for 2.18. Consideration will be taken for moving items back to 2.18 on a case-by-case basis (but is unlikely for enhancements)

Bugzilla 2.20 feature set is now frozen as of 15 Sept 2004. Anything flagged enhancement that hasn't already landed is being pushed out. If this bug is otherwise ready to land, we'll handle it on a case-by-case basis, please set the blocking2.20 flag to '?' if you think it qualifies.

This would be handled by a combination of bug 287330 and bug 308253.

The two dependent bugs have since been fixed.