Olav Vitters

In standard Bugzilla the bugmail header X-Bugzilla-Reason: CC could mean that you are on the C list or you are watching someone on the CC list. Bugmails from bugzilla.gnome.org have a patch to differentiate between those. X-Bugzilla-Reason: WatchCC is used when watching someone on the CC list and X-B-R: CC is only used when you are on the CC list.

In 2.20 the email code has been changed drastically. Fortunately above could be reimplemented. A new feature is the X-Bugzilla-Watching header. It is a comma separated list of email addresses you are watching for this bugreport.

It doesn’t work entirely like I’d want to. It can lists email addresses that have not caused the email to be sent. E.g. you are watching some person who has voted for a bug. In your email preferences you’ve disabled receiving bugmails when voting. Although the X-Bugzilla-Reason wouldn’t specify WatchVoter, the X-Bugzilla-Watching will specify the voter. This only happens when you receive the mail due to some other reason (example: you are the assignee). I’m not planning to fix this.

There are various ways to handle your spam problem. There are various spam detection problems, DNS blackhole lists, etc.

The worst way I can think of is letting others deal with your spam problem. When you send these persons an email, automatically a confirmation email comes back. That email explains you need to reply before they will see the message.

The thought behind these systems is that every reply will be read by a human being. A human being that cares enough to reply.

My main problem is that they make the spam problem worse. As they reply to every message, their ‘solution’ also replies to every spam message with a forged From address. I don’t believe I ever saw a spam message with the spammers email address in the From. When a spammer forges your From address, not only do you have to deal with the bounces, but also the mail bombs from the automated systems (such as these) responding to the spam. Some systems (majordomo) I can understand, but these confirmation systems are just stupid.

Automatically replying is bad, what makes it worse is that these systems do not even solve their problems for them. Perhaps they never want to receive their Bugzilla password. Bugmail mustn’t be important as well. I know some of these systems solve this by having a ‘pending’ folder. This allows the person to see the valid email between all the spam. Making the entire purpose of the confirmation system worthless.

For bugmail the bugmaster mailing list actually receives these confirmation messages. To the senders: go look in your pending folder.

Bugzilla.gnome.org currently runs a modified 2.16. It mostly does what we want, except for some of the niceties a newer Bugzilla will provide (search as RSS, better written code, …). The test version of the new Bugzilla can be seen at http://bugzilla-test.gnome.org/. Upcoming changes can be seen at http://live.gnome.org/BugzillaUpgrade, new suggestions are welcome. Current status of the upgrade will be tracked via http://live.gnome.org/BugzillaUpgrade/UpgradeStatus.

Gnome-blog is a great piece of software. For one it isn’t written in C, making it possible for me to hack on it (I do not want to know C). But to make this even better, the maintainer allows you to commit simple patches!

I started with triaging its bugs. Only then I discovered it was written in Python and started to write some patches for it. Discovering the policy on committing patches was like a dream come true. I do not often create patches, but when I do I want to create lots of ’em. After a while it gets messy to keep track of all of these changes. When this occurs I stop creating patches and wait for the maintainer to approve/ commit. Now I was able to commit and work on. In total I created 4 patches. I wanted to make more, but there weren’t enough simple bugs to fix. That may change, as with writing this post it is the first time I’ve actually used the software.. time to file some bugs.