Why you use trackers rather than multi-assigned bugs

Today seems to be the day of multi-assigned bugs, so I decided to write a few words on why you should not file a multi-assigned bug but rather file a tracker and then multiple bugs, which is what I do for the issues I found with tinderbox (and not just that) and the way I reached over 1500 bugs open at one point.

While creating new bugs means that you got more work to do, and even the bugzilla database gets loaded more, mutli-assigning a bug (that is creating a bug with a list of ebuilds involved and CCing all the maintainers of those ebuilds) means overloading the mail server and even worse the mailboxes of the developers involved. For each comment (useless or not) you get to send multiple emails, and it’s not extremely unlikely that a dev gets to receive multiple copies of the same comment if he’s on many aliases.

Even more obnoxious is when you get in a fight on whether that’s the correct way to proceed for one given package, and you get to have back and forth arguments between the filer (or the QA team, or whoever) and the maintainer of that package that get sent to multiple developers who are not involved and who are most likely not interested in the problem. Even worse, you have no clear timeline on when a bug was corrected for a given package, since the history is merged and you got to check on when someone commented, and de-CCed an alias from the bug.

The tracker method allows for the tracker to be visible by the QA team, which can monitor which bugs get fixed and which gets ignored, and each team only gets to see what they have to be concerned with. And to file the actual bugs, you can just use the ”Save as bookmarkable template” method that I also use to file my bugs.

So please use trackers and templated-bugs, I beg you!