A while ago my 19″ CRT died. I have been working on my spare 17″ CRT ever since. Until today:
For Bugzilla we need to update from two different cvs roots. One is upstream Bugzilla, the other cvs.gnome.org. Bugzilla-test wasn’t in gnome cvs because of the need to update from main Bugzilla. Thankfully Elijah created a script which updates from upstream Bugzilla, while still allowing our customizations to be in cvs.gnome.org. I understand it is a bit of a hack, but I am really happy with it. This also means bugzilla-test is now in cvs.
The current bugzilla.gnome.org is in cvs.gnome.org under bugzilla-new. Bugzilla-test can be found under bugzilla-newer. It likely needs some small handholding to setup locally; fixing that isn’t very high on my priority list. What I want to do next is to add back the patch statuses combo boxes in show_bug.cgi. As Bugzilla 2.20 (and even 2.18) has a lot of changes over 2.16, determining the best way to do this requires some thought. My main goal is to keep it useful while limiting the changes to 2.20.
Products added to bugzilla.gnome.org:
- Serpentine: An application for writing CD-Audio discs. It aims for simplicity, usability and compability
- OnTV: A GNOME Applet for monitoring current and upcoming
- Tepache: Tepache is a code sketcher for python that uses pygtk and glade.
It could look like other glade codegens, but it is totally different.
- Update manager: An application which makes it easy to manage, configure and
install software updates.
All use Python.
My parents and sister where in England for a 2 week holiday. Before traveling back they decided to visit London for a day, that day being today. They are all ok. Public telephones in London have a normal phone number. I really appreciated that as they only had one nearly empty mobile with them.
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.