LegNeato! Christian Legnitto's blog about Mozilla, Apple, technology, and random stuff

24Oct/11Off

A modest Bugzilla keyword format proposal

I just sent an email to dev-planning proposing a new keyword format. Nothing earth-shattering, but I think the upside is huge. I'll reproduce it here, but feel free to comment in the dev-planning thread.

Proposal

#(namespace)/..../(leafnode keyword)

That's it, pretty simple. Examples:

#relman/triage/needs-info
#relman/triage/defer-to-group
#ux/papercuts/user-control
#ux/papercuts/useful-error-messages
#crashkill/watching
#crashkill/blocklist-candidate
#crashkill/3rd-party/adobe
#crashkill/3rd-party/adobe/contacted
#gfx/bugkill/too-old
#gfx/bugkill/bitrot

...etc

Why?

  • "#" denotes a keyword that doesn't widely apply across the project
    1. Humans and tools can skip over easily
    2. Trivial bugzilla patch to make it sort at the bottom / last (I'll attach it to the bug in a bit). We can even filter them out of the autocomplete entirely if desired
    3. Trivial to make a watchdog script that enforces states and makes sure only certain people are adding / removing certain groups of keywords (which can be eventually expanded to a bz extension)
    4. Easy to let anyone with editbugs create them with a bugzilla patch (if desired)
  • "#" denotes a keyword in this system
    1. Tools can rely on the format and process it, unlike current keywords (is '-' part of the keyword or a namespace/separator? Depends!)
  • Hierarchical structure of tags
    1. Tools can query for keywords lists at the proper depth easily
    2. Humans can easily group keywords at a glance
    3. Humans can query easily through the existing bugzilla interface (e.g "show me everything Release Management is triaging")
  • Keyword subsections can use whatever rules they like, only "#" in the 1st position and "/" anywhere is special (spaces obviously don't work)
  • (ab)using the current keyword system. This is essentially a small step to moving keywords into a tree model, rooted via component. I need something NOW and can't wait for bugzilla improvements (and already have enough of them assigned to me).

Why not use the whiteboard?

The whiteboard is junk! I can't do historical queries for when a whiteboard substring was removed. The bugmail isn't explicitly clear and I have to take time to scan the string, fun regex stuff in scripts, etc.

If bugzilla had a decent keyword or tag system the whiteboard would go away...it's a kludge.

Future plans?

  • Make anyone able to grab a "#" namespace and then create as many keywords as they want inside without having the current heavy-weight keyword access. This should actually be easy to do in bugzilla
  • Release Management may migrate this sort of stuff to our web system outside Bugzilla, but for now we're (ab)using current tools
  • We need to replace Bugzilla's keyword system. Yesterday.

Please let me know what you think and if you or your group would find such a change useful. The goal would be for it to be invisible to anyone who isn't using it and wildly useful to those who do.

26Jul/10Off

Side projects for me in the coming weeks

I am going to focus on these side projects in the coming weeks, in addition to driving the Firefox security releases. If you see anything missing or something that needs my attention, please let me know.

Projects in order of importance

  1. Patch for Bugzilla to add rich bug relations.
    This will give us greater confidence that bugs aren't missed/overlooked. It will also help development by organizing bugs consistently and allow for richer tools, processes, and progress reporting
  2. Create a new "release management" system that will manage all aspects of a release.
    This will allow consistent processes between different teams/releases, make sure nothing is missed, add checking tools, and generally become the "truth" when it comes to release metadata (schedule, state, status, etc)
  3. Get Mozilla Pulse (http://pulse.mozilla.org) solid, usable, and useful.
    Pulse has the opportunity to make all systems at Mozilla better. I hit some bumps with RabbitMQ but will be working on ironing them out and providing a scalable, HA system that can later be handed over to another team
  4. Create a triage reporting tool.
    This will make the approval processes more open by publishing triage notes and results. It will also be a place to put action items so that they are acted upon before the next triage session
  5. Finish new release note framework.
    I started this when I first came but got tied up in other projects. The way we do release notes involves a lot of copy and paste, it is difficult for QA to create automated tests, etc. I intend to fix this
  6. Patch for TabCandy to support user-defined rules.
    The response to TabCandy has been great, but I think having this feature will be essential for power users and those who don't want to manually organize tab groups. I've looked at the TabCandy code a bit and this shouldn't be too hard to hack in. I may work on this a bit as a breather from the above projects (but probably not)

If you have any ideas about these systems (or others you think release management needs), please let me know!