Pidgin News

As bug master for Pidgin, I bear a lot of the responsibility for triaging bugs--getting them assigned to the appropriate developers, weeding out the invalid bugs, etc. I admit that lately I’ve not been doing such a good job at this. I’ve been ignoring Pidgin so I could relax and unplug somewhat after the stress of work. Thankfully, in my increased absence, my fellow developers, particularly Paul, Daniel, and Elliott, have been picking up the slack. All the while, however, not much has changed as far as actual ticket resolution goes.

As much as I hate quoting numbers, let’s take a look at some (as of 2010-01-31, 0500 UTC) to get an idea of scope:

• Historical ticket count: 11270
• Currently open tickets: 1818
• Open bugs: 958
• Open bugs awaiting response from reporter: 11
• Bugs that can’t be fixed until we’re ready for 3.0.0: 19

Obviously, 958 open bugs is unacceptable. But to put those bugs in perspective, let’s look at how they break down:

• AIM: 64
• artwork: 9
• Bonjour: 4
• custom emoticons: 2
• finch: 7
• Gadu-Gadu: 19
• Google Talk: 3
• Groupwise: 7
• ICQ: 47
• IRC: 26
• libpurple: 68
• MSN: 70
• MySpace: 17
• pidgin: 198
• plugins: 28
• QQ: 23
• Sametime: 13
• SILC: 6
• SIMPLE: 3
• trac: 4
• unclassified: 160
• Voice and Video: 11
• webpage: 3
• winpidgin: 81
• XMPP: 47
• Yahoo!: 35
• Zephyr: 3

Now, yes, on an IM service level, MSN has more open tickets than any other listed service. However, looking at the underlying protocol for these services, AIM and ICQ combined give the OSCAR protocol a 41-ticket lead. Google Talk is an XMPP service, but even combining Google Talk and XMPP numbers, we come up with 50 tickets, trailing MSN by 20. None of our other listed IM services share an underlying protocol with another. In fairness, the unclassified bugs really should be sorted into proper components, which would change these numbers, but at this time I don’t know by how much.

Now, looking at the IM services we support, many of them don’t have a current “maintainer” who is ultimately responsible for the plugin. Currently, Zephyr, Yahoo, SIMPLE, SILC, Sametime, MySpace, Groupwise, Bonjour, and QQ either have no “official” maintainer, have no one at all working on them, or haven’t had meaningful development activity in at least three months. Obviously, protocols without an active maintainer are not going to see much in the way of quick bug resolution.

We‘re often asked, “Why don’t protocols have maintainers?” or “Why don’t you spend time working on bugs?" or a hundred other questions about the lack of time spent working on Pidgin. The reasons for this are many:

• We’re all volunteers. Not a single one of us gets paid to put any time or effort into Pidgin.
• Not all of us use all the services we support. I’ll use myself as an example here. I use AIM, ICQ, Yahoo!, and XMPP regularly. I also have an MSN account that I couldn’t possibly care less about and a couple IRC accounts for the rare instance that I need to test something with the Purple Plugin Pack. I don’t use, nor do I have interest in using, any of the other services.
• We all have families that we’d like to spend time with. Many of us have spouses/significant others, and a few of us also have children. Family is a demand on our time that should never be ignored.
• All (or almost all) of us have jobs. Since, as I already mentioned, we’re volunteers, the jobs with which we earn our paychecks have to take priority.
• We’re human too--we get burned out, experience stress, need to unwind after work, etc.
• Not all of us know anything about a given protocol, nor can we be reasonably expected to. For example, I don’t know how the MSN protocol works, and I have no desire to learn about it. We don’t have to be experts in a given protocol if we don’t want to be. Also, the fact that MSN is allegedly the most-used protocol in the world is not a valid reason for anyone to expect us all to be experts on (or even to care about) the protocol.
• Pidgin largely just works for us. If we don’t see a bug, we’re not going to be irritated by it and sit down to try to fix it.

So yes, we have been “neglecting” Pidgin to a certain extent. Our time is a precious resource, and in many cases we simply have better things to do or simply don’t have the time to sit down and attack bugs to get them closed. That’s not to say that our development process is coming to an end or that we’re abandoning Pidgin, though. We do, however, readily admit that we need fresh blood.

In that vein, I’m calling for you, the Pidgin community, to help us. Take a look at the open bugs and feature requests and submit patches to resolve them. Pidgin is a fairly complex beast, and there’s a lot of code to maintain, but it is manageable if people work on small changes at a time (instead of completely rearranging things unnecessarily). Additionally, Pidgin uses a distributed version control system, monotone. Contributors who want to seriously work on Pidgin can use this to their advantage by creating their own branches in monotone. When contributions are ready, those contributors can submit the changes from their branches either by attaching patches to tickets on trac or by asking a Pidgin developer to pull and review the changes. At that point a developer can commit or merge the changes and push them on to the central repo at mtn.pidgin.im.

The only problem with the model of a developer pulling changes from a contributor is that in order for someone to pull revisions, the contributor must be able to run mtn in server mode, which isn’t always possible or feasible. I’m trying to come up with some custom lua code to help in this regard, to do something similar to what git and hg can do with emailing patches, but that’s going to take some time, as I need to learn some more of the internals of monotone first. But none of this should stop anyone from trying to contribute! We will still accept single one-off patches or sets of patches and series of patches from longer-term contributors, and using monotone to develop against is going to produce patches that are the easiest for all of us to work with.

So, yes, in short, Help Wanted and Needed!

In my last blog post, I alluded to our quest to make Pidgin perfect (in our own eyes, at least). This is a quest that by its very definition can never end, because as we near "perfection," there will always be something else that crops up to demonstrate we haven't reached perfection quite yet. This "quest" can have elements of many different forms. A few months ago, one of those forms was discussed on our development mailing list.

As a good many people are aware, Pidgin has long supported GTK+ and GLib 2.0.0. Several years ago when GTK+ 2.0.0 first came out, we underwent a nine-month rewrite of our user interface (UI) to move from the older GTK+ 1.2.10 (or newer) to the new GTK+ 2.0.0. Since that time, until 2.6.0, we've always maintained compatibility with GTK+ 2.0.0 through the use of conditional code that disabled certain features or UI elements that required newer versions of GTK+ or GLib than what was available at compile time. In some cases, we had conditional use of code to work around the lack of certain convenience functions present in newer versions of GTK+ or GLib. In still other cases, we actually carried (that is, distributed in our source tarballs and compiled where necessary) the source of several GTK+ widgets in order to make our UI work for users with older versions of GTK+. Over the years, this has become more cumbersome, to the point that for 2.6.x, it became impractical to maintain compatibility with GTK+ 2.0.0--when we realized this, we changed our requirements to GTK+ and GLib 2.4.0, which contained the features we needed.

The increased difficulty of supporting older libraries prompted me to bring a discussion up on our development list prior to the release of 2.6.0 asking for a vote, discussion, etc. on raising minimum GLib and GTK+ version requirements for Pidgin 2.7.0. This discussion has come up before and been shot down. This time, I put it to a vote and gave quite a while for votes to be cast. There were no "No" votes cast. The versions we voted on were GLib 2.12.0 and GTK+ 2.10.0. These versions allow us to support reasonably recent Linux and UNIX systems, as those GTK+ and GLib versions were 3 years old at the time of the vote, while also making our lives significantly easier since we no longer have to care about really old versions of GTK+ or GLib. Ideally, I would have liked to have GLib 2.14.0 and GTK+ 2.12.0 as the minimums, but I was trying to reach a middle ground that would avoid angering too many people.

This change in the minimum required GTK+ and GLib versions has a few consequences. Obviously, Linux and UNIX distributions that don't ship GTK+ 2.10.0 or newer won't be able to support Pidgin 2.7.0 when we release it. On these systems, users can, however, compile GTK+, GLib, and friends, then compile Pidgin. This is really a lot of work, but some users may be willing to go through it.

For our Windows users, there will be some major changes. When building and linking our releases, we'll be stepping up to GLib 2.18.0 and GTK+ 2.14.0. We already ship this version or newer in our installers, but now we'll actually be linking against these versions. The consequences of this are that Windows NT 4.0, Windows 98, and Windows ME will no longer be supported. These newer versions of GTK+ and GLib require features that just aren't present in those old operating systems. None of these operating systems have been commercially supported (by this I mean modern games, word processors, spreadsheets, etc.) for years, and even projects like Firefox have stopped supporting them.

Additionally, our Windows expert, Daniel, has made some changes to the Pidgin installer and to our crash report generation for 2.7.0:

• Instead of installing GTK+ in a system-wide configuration, we will be changing to installing GTK+ local to Pidgin. This means that it should be harder for us to conflict with other GTK+ applications on Windows. This has long been requested, but we just finally got around to doing it.
• Debug symbols can now be read from parallel copies of files. Normal installations of Pidgin ship "stripped" binaries--that is, there is no information useful for generating crash reports. Now, instead of replacing all the existing files, the installer will offer the option to install debug symbols. Selecting this option will install parallel, unstripped copies of every file with the extension ".dbgsym" to a special location.
• The installer will allow choosing which Pidgin translations to install.
• The installer will have "online" and "offline" variants. The "online" variant will include only Pidgin. GTK+ and debug symbols will be downloaded as needed. The "offline" variant will include both GTK+ and the debug symbols.

Also among the changes coming up for Pidgin 2.7.0 is the switch from the eggtrayicon widget we have carried in our source tarball for years to the GtkStatusIcon implementation that was added in GTK+ 2.10.0. There are still a few bugs to work out with this change, but I believe once we have those ironed out, our notification area icon will behave better for a number of users who have been experiencing difficulties.

Of course, these changes aren't the only ones that will make it into 2.7.0. I have my own plans for a few additions, plus I won't allow 2.7.0 to be released without a few other features being merged in. But so far, it looks like Pidgin 2.7.0 will make some long-awaited forward strides. Hopefully everyone enjoys it!

Also, to those who celebrate the holiday, Merry Christmas!

This has been on my todo list forever, and I started tinkering with it the other day. But after a mega hackathon tonight, I have a pretty functional gtkdoc plugin from trac.

The idea of the plugin is to integrate gtkdoc books into trac's interface. This is accomplished, currently, by and iframe displaying the actual htlm output of gtkdoc, as well as integrating into the search engine in trac.

There's two new user permissions in this plugin, GTKDOC_VIEW and GTKDOC_ADMIN. GTKDOC_VIEW is obviously to view the api and well as search it, where admin allows the addition and removal of books.

As mentioned above the admin interface provides an interface for adding and removing books. Books are keyed on a name given to them at the time they're added, as well as an absolute path on the local filesystem of where the book actually is. This way, you can update the documentation and not have to touch a thing in trac.

At any rate, it's still pretty rough around the edges and lacking a ton of error checking. But feel free to grab it from our extras repo (hg clone http://hg.guifications.org/extras) and tinker with it. It's in trac/gtkdoc, use the normal "python setup.py bdist_egg" to build it.

Recently I've been frustrated by the fact that we have a number of tickets open on Pidgin's Trac that deal with inadequacies in the preferences window. The biggest complaint is that in a number of configurations, the preferences window is too tall to fit on a screen. This has only recently become a problem with the advent of the so-called "netbook" with their nearly microscopic screens (seriously, how do people use those things when they have such tiny screens? It drives me absolutely nuts when I try to use one).

Prior to the netbook craze, we've always aimed for all our windows, dialogs, etc. to fit on an 800x600 screen. With the shorter and wider screens found on netbooks, 800x600 isn't realistic anymore. In that vein, I've started working on paring down Pidgin's preferences window to fit better on a netbook screen. Let's take a look at what I've done so far.

The first, and most obvious, change I've made is to move the tabs that were previously at the top of the preferences window to the side. I did this for two reasons--in my environment, I have a Browser tab because I don't use Windows or GNOME. This meant the tabs artificially forced my window to be wider than it strictly needed to be (our preference window "notebook," as it's called in GTK+ parlance, doesn't scroll or stack the tab row). Second, moving the tabs from the top to the left gains back some valuable pixels that help us fit on those really short screens. In retrospect, I didn't gain much--only about 20 pixels or so in my configuration--with the width of the actual pages of the notebook because of other changes I made to help the height. But every pixel of height counts to make us fit on short screens.

After that, I started picking on the Network tab. We have a lot of stuff that's just crammed into the Network tab. FIrst we have a bunch of stuff for automatically detecting your public IP address or optionally manually specifying one. Then we have some stuff for port forwarding. After that comes stuff for TURN relay servers, which is yet another method for traversing NAT "routers." Finally, we have the wonderful proxy server stuff. All this stuff being crammed on a single tab makes the dialog ridiculously tall and makes the Network tab tied with the Conversations tab for biggest overall height.

Clearly, a few changes were in order here. I made a minor change here that moved the port range spin buttons to be on the same "line" as the checkbox that enables and disables them. Beyond that, there were still a lot of changes that could be beneficial. For example, now that I've made the notebook tabs go down the left side of the window, that gives us a lot of room to better organize our preferences into tabs that make logical sense. Since I had this extra tab room to work with, it made sense to add a new tab to put the proxy configuration options on. While a proxy server is obviously a network configuration item, it's not always obvious to our users that the Network tab is the correct place to configure the global proxy settings.

Now, looking at the Smiley Themes tab, there's a crapton of wasted space there. Seemed to me like a perfect candidate to be the target of some moves. Over on the Interface tab, we have two theme selectors--one for buddy list themes and the other for status icon themes. I decided those were a better fit on a dedicated Themes tab, so I renamed the Smiley Themes tab to Themes and slapped those theme selectors in above the smiley theme selector. I also excised the sound theme selector from the Sounds tab and slapped it into the newly-renamed Themes tab. Elliott, another Pidgin developer, converted the smiley theme selector to be consistent with the other theme selectors. Now the Themes tab doesn't seem under-utilized, but it does still need a little work.

I also decided to reorder the tabs. I ordered them alphabetically, but intentionally left the Interface tab as our first tab. It seems to be convention that the "General" tab is the first tab in a notebook for a preferences window. In that vein, our Interface tab is our equivalent to a General tab, so I left it first to fit with convention. The order of the other tabs should be something logical. Sure, I could have grouped Browser, Network, and Proxy together, then grouped Conversations and Logging together, and later figured out where to stuff Sounds and Status/Idle, but an alphabetical arrangement is just as sensible considering that not all our tabs clearly separate into logical groups.

The next things to get rid of were the "Sound Method" section on the Sounds tab and the Auto-away section on the Status/Idle tab. Note here that I didn't actually remove any preferences; I simply removed a section and placed the relevant preferences in another section. The existing groupings seemed redundant and excessive. This seems better to me.

There, was, however, one thing I needed to give the axe to. Over on the Conversations tab, there was this annoying preference section called "Font" that contained two preferences designed to allow users to override the GTK+ theme settings, but only for the conversation history pane. This preference serves very little purpose anywhere but on Windows, so I removed it. I then made sure the Pidgin GTK+ Theme Control plugin could control the history area font. There were some objections about unconditionally removing this preference, so I compromised and made it available only on Windows, even though I fail to see why the plugin isn't sufficient to control this font.

In the end, I believe I accomplished my initial goal of making the preferences window fit on smaller screens, but I also managed to make it so the dialog still fits on an 800x600 screen. The new window measures 698 pixels wide and 492 pixels high in my configuration, which is a bit too big for 640x480, but will fit with plenty of room to spare on 800x600 and should fit pretty well on just about any netbook screen.

You can take a look at what the new window will look like with these pictures (sorry, but the order is backwards and I'm too lazy to fix it):










This will be in Pidgin 2.6.4 when we release it. Hopefully everyone enjoys the changes!

Have you ever taken a look at the text in Pidgin's About box? If not, do so now. Click the Help menu, then click "About." Be prepared to scroll. And scroll. And scroll some more. And again. Until finally you reach the end of the thing and see a crapton of build-related information that probably doesn't make a whole lot of sense. Along the way, you'll scroll through a list of our developers and crazy patch writers, then through a list of retired developers and retired crazy patch writers, then through translators and retired translators. The list of translators, especially, seems to go on forever. The amount of information in that box has grown nearly exponentially in the last couple years.

Get tired of scrolling through all that information? Me too. And apparently a bunch of other people--I've seen a number of complaints from people involved with several Linux distributions indicating that our about box has way too much information. Well, this morning, I set out to remedy that.

Remember that insanely long list of current and retired translators? Well, when we release Pidgin 2.7.0, it will no longer be in the About box. To excise this information from the About box, I created a new entry on the Help menu called "Translator Information" that pops up a new dialog similar to the About box. This new dialog lists all current and retired translators.

Once the translators were gone from the About box, the next largest chunk of text was the "Debugging Information" section all the way at the bottom. Considering how frequently we ask users to look at this information, it is nowhere near visible enough sitting at the bottom of the About box's scrollable area. This, too, became its own window, accessible at "Build Information" on the Help menu. (As an interesting side note, this is insanely long in code, too. In fact, it's more lines of code than the printed list of translators takes up in the new translator info dialog!)

Even losing all that text from the dialog wasn't good enough for me. Next I axed the list of developers, crazy patch writers, and retired developers and crazy patch writers. Now these lists are available by clicking "Developer Information" on the Help menu. Since I'd just added three items to the Help menu, it was time to toss a couple menu separators in there so that things look more organized and cleaner. Hey, our Help menu is kinda respectable now!

Now I looked at the about box again. It still felt too verbose to me. Granted, a lot of that information is important, but I started thinking about better ways to say the same things. For a great example, let's look at the first two blobs of text you see after the version info:

Pidgin is a graphical modular messaging client based on libpurple which is capable of connecting to AIM, MSN, Yahoo!, XMPP, ICQ, IRC, SILC, SIP/SIMPLE, Novell GroupWise, Lotus Sametime, Bonjour, Zephyr, MySpaceIM, Gadu-Gadu, and QQ all at once. It is written using GTK+.

You may modify and redistribute the program under the terms of the GPL (version 2 or later). A copy of the GPL is contained in the 'COPYING' file distributed with Pidgin. Pidgin is copyrighted by its contributors. See the 'COPYRIGHT' file for the complete list of contributors. We provide no warranty for this program.

All this information is hugely important. But it's too long. So I tried a surgical strike on the words. It took a few more tries than I care to admit, but I found that I liked this text better:

Pidgin is a messaging client based on libpurple which is capable of connecting to multiple messaging services at once. Pidgin is written in C using GTK+. Pidgin is released, and may be modified and redistributed, under the terms of the GPL version 2 (or later). A copy of the GPL is distributed with Pidgin. Pidgin is copyrighted by its contributors, a list of whom is also distributed with Pidgin. There is no warranty for Pidgin.

Obviously I took away some information, namely which IM services Pidgin can connect to. I'm not convinced that needs to be in the about box, considering the exact same text that is in Pidgin 2.6.2's About box is on Pidgin's website. So I carefully dissected the text and came up with a shorter text that gets all the important information across while cutting information most users aren't going to care about reading. I even managed to squeeze in that Pidgin is written in C, which was previously missing (it's a ridiculously frequently asked question).

Now I had something better. But I could still improve it. We had oversized text pointing to pidgin.im, the FAQ, the IRC channel, and our XMPP conference. I added a new, bold heading, "Helpful Resources," and added those items as indented, normal-sized text items under the heading. This was getting better. Now, one final improvement. We point out that help from other Pidgin users is available by emailing support@pidgin.im. I changed the heading a little so that it reads a bit better. I also changed "3rd party" to "third-party," which is the more correct form.

Something still seemed wrong about the About box, though. I experimented with the size, making it default to 450x450 pixels like the new dialogs I added. This seemed to help a lot. I'd like to make it a touch larger still, but I'm afraid that making it any larger will make it a tight fit on netbook screens. We're already getting complaints that some of our windows don't fit on these smaller screens, so I'm not exactly eager to cause more complaints.

At any rate, for me, the About box's text fits in just under two full "pages" of the scrollable area--that is, the last line of the scrollable area when scrolled all the way to the top is the first line when scrolled all the way to the bottom. There are some other minor tweaks I'm going to look at making that may make the area scroll even less.

In the end, my boredom caused me to take a look at something people have been complaining about for ages. Overall, I think what I've done is a good thing, but we won't really know for sure until we release Pidgin 2.7.0 (don't ask when--we have no idea yet!) and people see the new dialogs. I hope everyone likes what I did!

Well, by now most people probably realize that we've released Pidgin 2.6.0. It feels like this has been in the works forever, particularly these last couple weeks.

First off, some statistics for this release:

• 99 bullet points in the ChangeLog.
• 221 tickets closed for the release (that is, 221 tickets that we believe are fixed or are patches that we accepted).
• 2 major new features
• More other new features than I care to count
  

For the new features:

Voice and Video support - Thanks to Mike Ruprecht and his Summer of Code project from 2008, libpurple now has a voice and video framework that can be used to add these features to our protocol plugins. Currently we support these features only on XMPP, but Mike is working on other protocols as I write this and hopes to have more protocols at least partially supported soon. The dependencies are a bit of a mess for the uninitiated, but unfortunately that's unavoidable. I'm hoping most distributions will be able to catch up with this soon and make it completely effortless for users, but this is a headache even for some distributions. The biggest setback thus far is we're currently not able to support these features on Windows--but we're working on it! Please be patient!

Theme support - Another Summer of Code project from 2008, this time by Justin Rodriguez, adds theming support to libpurple and Pidgin. This currently isn't very well documented at all, but themes are now supported for the buddy list, sounds, and status icons.

Yahoo users will notice a few changes. First and foremost, we split the Yahoo protocol plugin into two, one to handle the Yahoo JAPAN network and one to handle the rest of the world's Yahoo network. This has the side effect that if you happen to have the exact same account registered on both networks, you'll finally be able to use both accounts in Pidgin. It's also a lot more obvious to people looking to use their Yahoo JAPAN accounts in Pidgin. Sulabh Mahajan, another Summer of Code student from 2008, implemented a ton of new stuff for Yahoo and Yahoo JAPAN. Among the changes are the addition of SMS support. You can now send SMS messages by sending to "+<country code><phone number>". Sulabh also implemented peer-to-peer file transfers for Yahoo as well as adding MSN buddies to the buddy list of a Yahoo account. Unfortunately, proper support of adding MSN buddies isn't possible to do until 3.0.0 when we can make some major changes to the internal workings, but for now, if you want to add an MSN buddy to a Yahoo account, add them as "msn/foo@bar.tld". The "msn/" is the important part--this tells our Yahoo code to look across the MSN bridge to add the buddy.

On top of all this, our developers, crazy patch writers, and contributors have been pouring a ton of work into our XMPP support. Beyond the voice and video support, we've gained a service discovery ("disco" for those familiar with the term) browser plugin, support for BOSH (Bytestreams Over Synchronous HTTP), idle time reporting (XEP-0256), attention ("buzzing") support (XEP-0224), in-band bytestreams file transfer as a last-resort transfer method (XEP-0047), custom smiley support in small (less than 10 users) MUC's via the "bits of binary" extension, as well as updated support for buddy icons (User Avatar XEP-0084 v1.1). There have also been a ton of bug fixes and other enhancements. All this adds up to 29 bullet points in the changelog for XMPP alone, and even that is surely not 100% complete.

Other notable items include our new (optional) support for GNU libidn, allowing us to support UTF-8 domain names throughout all of libpurple, three new environment variables that can help in debugging (and thus possibly help some plugin authors as well), a new authentication mechanism for AIM implemented at AOL's request, the ability to receive voice clips and handwritten (ink) messages on MSN, and a crapton of fixes and enhancements in Pidgin. Even Finch got some love this time around, gaining a new TinyURL plugin and some important bug fixes.

Of course, I'd be neglecting important details if I didn't mention the security issue we fixed for this release, as well as the 2.5.9 release. CORE Security Technologies found a way to remotely crash a running Pidgin instance that was logged into an MSN account via two specially crafted messages. They were kind and responsible enough to inform us of this privately and provide us with a proof of concept script so we could fix the problem before they made it public. The release of Pidgin 2.5.9 was done in source form only, explicitly to provide distribution packagers with a fixed release in the event they preferred to avoid the behemoth release that is 2.6.0.

Of course, since I was heavily involved in the creation of the 2.6.0 release, we have some issues that we're going to need to follow up on shortly with a 2.6.1. I'm sorry for any inconvenience this causes anyone, but hopefully 2.6.1's release will make up for it by being what 2.6.0 should have been. At any rate, enjoy all the shiny new features!

Well, Casey already pointed out that we released Pidgin 2.5.8, but I thought I would expand on that a bit.

As everyone reading this knows already, Yahoo was broken for us briefly. We rushed out a 2.5.7 release to address the problem and after release discovered that we had a number of other problems. Among these were broken file transfers, broken buddy icons, etc.

We were receiving almost as many complaints about buddies never changing to show as offline as we got about the original Yahoo connection problem. Quite frankly, I got tired of it, so I started grabbing additional changes that we had committed to the upcoming 2.6.0 and applying them to 2.5.7. Eventually this yielded 2.5.8, which turned out to take a lot longer than I expected to get released.

As the ChangeLog indicates, we fixed a bunch of stuff, including an ICQ crash, an MSN crash for users with long buddy lists, a Yahoo crash introduced in 2.5.7, as well as receiving messages from the web version of MySpace IM and signing on to MySpace IM if you have an empty buddy list.

If you're not using Pidgin 2.5.8, upgrade!

We're also busily at work on Pidgin 2.6.0. In recent weeks we've come down to just a few things holding up the release. Among the blockers are the merging of some new features and fixing a new crash that we introduced by fixing ther crashes. At this rate, we might actually get 2.6.0 out sometime this year!

On an unrelated side note, I was recruited to participate in a charity fundraiser for the Muscular Distrophy Association. If anyone would like to help me reach my fundraising goal, I'd appreciate it.

I just went ahead and fixed the links on our site to match the new "streamlined" download system SourceForge pushed yesterday. If you were trying to download before and getting errors, you should be able to download successfully now. If you are still getting errors, there's probably nothing we can do but wait for SourceForge to fix it.

It's a mystery to us why the old download links weren't maintained for backwards compatibility, but hopefully they won't make any further changes that break downloads again for a while.

As many of you may have noticed, Yahoo stopped working for all users not long ago. We quickly pushed out 2.5.7 but several issues remained (such as crashes, phantom buddies, and being unable to compile).

2.5.8 is now released, which should resolve (we hope!) the remaining problems.

You can download 2.5.8 at www.pidgin.im

From the recent activity on our support mailing list and in our IRC channel (#pidgin on irc.freenode.net), it's plain to see there is still a LOT of confusion about the recent troubles logging into Yahoo Messenger via Pidgin. I'm going to try to clear some of the confusion up. I apologize for the technical nature of this post. Feel free to skip ahead to the last paragraph of "Solving the Problem" below if you don't care what the problem is and just want to fix it. Or take the simple approach and just upgrade to Pidgin 2.5.7 and skip down to "But I already upgraded! It still doesn't work!" if you still have trouble.

The Problem

The specific problem that affected us is the authentication mechanism. Yahoo Messenger 6 used a spectacularly complicated password obfuscation method to "encrypt" the password as it was being sent over the wire to Yahoo's servers. Back in 2004 when we were preparing our 0.79 release, Cerulean Studios, the creators of the Trillian client, were kind enough to implement this authentication mechanism for us. As part of this change, we began to identify to the Yahoo servers as Yahoo Messenger 6. This was all fine and well.

The real problem came relatively recently. At some point in our recent history, which I honestly don't feel like tracking down now, we started identifying as Yahoo Messenger 7. At some point after that we again updated to identify as Yahoo Messenger 8. Both of these changes were related to file transfer and other feature enhancements. When we made these changes, however, we never updated our authentication code. This means we were claiming to speak Yahoo Protocol version 15 but we authenticated the same way protocol version 13 clients do. Even this worked for quite some time.

Yahoo began upgrading their servers at some point recently to phase out the old Yahoo Messenger 6 client. In effect, they want to force users of older software to update to the current client. Whether this is a good thing or not depends on your perspective. From Yahoo's point of view, I'm sure this is an excellent move, as it should make their server software simpler (speak one less protocol, one less auth scheme, etc.) and reduce their support load (fewer client versions to deal with). Where it became a problem for us is that at the same time, they started requiring protocol version 15 clients to speak the version 15 authentication scheme, which we never implemented. Since we still spoke version 13's authentication, this cut us off entirely.

[Note: Some users have discovered that not all of the Yahoo Messenger servers are rejecting the old authentication mechanism from Pidgin. The number of servers that still accept it appears to be shrinking, however. We advise upgrading to Pidgin 2.5.7 as soon as possible.]

Solving the Problem

A few months ago, a kind soul pointed out to us documentation he had assembled on how the current Yahoo Messenger client authenticated and communicated with the servers. It turns out that the convoluted authentication mechanism we had used for years was replaced with a significantly simpler one that uses a few simple HTTPS requests. The beauty here is the login data is encrypted in the same manner as your communications are encrypted whenever you purchase merchandise at a retailer like Amazon. This makes it significantly simpler for us, and probably allows Yahoo to simplify things on their end as well while increasing security during the login process for all their users.

As I mentioned in my previous post, two of our Summer of Code students, Sulabh Mahajan and Mike Ruprecht (keep an eye out for these names--they're responsible for chunks of Pidgin 2.6.0's changelog!), implemented this new authentication scheme. We eventually merged it into what will become Pidgin 2.6.0. This code has had some quality testing already, thanks to the guys over at Adium.

In response to the Yahoo server changes, I (quickly) yanked the most important changes for this new authentication scheme and slapped them onto Pidgin 2.5.6. After some testing and some other important bug fixes, we kicked Pidgin 2.5.7 out the door. In theory, upgrading to Pidgin 2.5.7 should make most people's Yahoo problems go away.

But I already upgraded! It still doesn't work!

Yeah, we have had a few people with this problem. Here are a few suggestions:

• Change your Yahoo account's Pager Server field (located on the Advanced tab when editing the account) to 'scsa.msg.yahoo.com', especially if you previously read this document
• If you're crashing when you connect your Yahoo account, again, set your Pager Server to 'scsa.msg.yahoo.com' and try to log in again. If you can't edit your account, you have two options:
• Run Pidgin from a shell (command prompt). 'pidgin -n' will cause Pidgin to start up in an Offline status, thus allowing you to edit your accounts. Set the Pager Server as described above.
  
• If you know the name of the server that you entered in the Pager Server field, you can change this manually. Locate your .purple directory (covered in the FAQ!). In this directory is a file called accounts.xml. Open this file with an editor (Wordpad on Windows; any text editor will do on Linux and other Unix-like systems) and find the server name you entered. Change this value and save the file. Start Pidgin and you should be fine.
  
• If you upgraded by compiling Pidgin yourself, make sure you removed your distribution's existing libpurple package (for Ubuntu and Debian users this is libpurple0; for RedHat/Fedora users it should be libpurple). Then run 'sudo ldconfig' (or 'ldconfig' if you have a root shell already) and try again.
• If you're behind a proxy server that proxies HTTP connections but not HTTPS connections, and you have to explicitly configure the proxy in Pidgin, you're probably not going to have any luck. Our current proxy code can't handle this kind of configuration. Sorry.
• If you're on Windows and you get errors about a corrupted installer, clear your browser's cache, then restart your browser and try to download again.

But I can't upgrade!

If you really can't upgrade, then try setting the pager server to either 'scsc.msg.yahoo.com' or 'cs101.msg.mud.yahoo.com' and try again. But you really, really, really, really should upgrade. If you do eventually upgrade, you'll have to change this again, as I describe above.

I upgraded but now ______________ doesn't work!

We've had some reports that after upgrading there are some issues such as missing buddy icons and buddies never being shown as signed off. We are looking into these issues and hope to have them fixed for Pidgin 2.6.0. These issues didn't show up in my testing before the 2.5.7 release.

Tracking Yahoo Problems

Please don't open any new tickets about these issues or about not being able to log in. There are already open tickets to track them. Please also don't comment with "Me too!" or similar on these tickets--it just creates more noise for us to sort through when we're working on Pidgin. If you want to express a "Me too" on one of the tickets, click the arrow near the top of the ticket page that's pointing up. This will cast a vote for the ticket.

I hope this information is helpful to people.

By now it's no great secret that Yahoo has decided to break clients that use outdated authentication code. The result of that change is that Pidgin 2.5.6 and older no longer work unless you connect to one of a very few servers left that still speak the old authentication mechanism. We knew this change was upcoming, but all indications we saw pointed to us having almost another two months to push a release with updated authentication code.

All that aside, we've had some updated authentication code for a while now, and were originally waiting to include it in the Pidgin 2.6.0 release. However, since Yahoo made the authentication changes earlier than we expected, we had to react as quickly as possible to stop the flow of incoming complaints. As a result, we backported the Yahoo authentication changes so we could cut a Pidgin 2.5.7 release fairly quickly.

Pidgin 2.5.7 is now released and does work to connect to Yahoo.

Just for the record, I'd also like to point out to those who complained about waiting three days to get a working release that the last time Yahoo screwed with authentication, it took over a week to even get code to fix the problem, let alone prepare a release and actually get it out to users.

Additionally, we fixed the annoying MSN disconnect-on-block issue and changed AIM's behavior such that the "could not retrieve your buddy list" error appears only once per AIM account.

Enjoy the new release!

I imagine most people who bother to read this blog know that I am rather fond of Monotone, the distributed version control system (a.k.a. DVCS) that we use to maintain Pidgin's code. One of the most convenient features of monotone is that it's extensible via the Lua scripting language. Over our time using monotone, some of us have come across (or written!) some useful snippets of lua code that can be tossed into ~/.monotone/monotonerc to make things easier on us.

The first such snippet is pretty simple. I have three monotone keys that I use for various purposes. One is for Pidgin development, another is for my work on the Guifications project and the Purple Plugin Pack. The third is for my private projects. Instead of needing to remember to specify which key I want to use in specific circumstances, a small snippet of lua can take care of this for me (of course, anyone wanting to use this will need to edit branch patterns and key names appropriately):

function get_branch_key (branch)
    d = { ["im.pidgin"]="rekkanoryo@pidgin.im",
          ["org.guifications"]="rekkanoryo@guifications.org",
          ["org.rekkanoryo"]="rekkanoryo@rekkanoryo.org"
    }

    for k, v in pairs(d) do
        if string.find(branch, k) then
            return v
        end
    end
end

Monotone also has the ability to cherry-pick revisions from one branch to transplant into another. (Of course, I recognize that other DVCS tools have this capability too.) To do this, ordinarily we would issue a command like mtn pluck some_revision_id within a working copy of the branch we want to transplant the revision to. In our experience, the default log messages for a pluck leave some to be desired. My fellow developer Sadrul wrote this cool bit to add a pluck-log command to Monotone.

The pluck-log command takes a series of individual revision ID's as arguments. For each revision ID in the list of arguments, the command will execute mtn pluck $REV to grab and apply the changes to the workspace. Additionally, the plucked revision's original changelog entry will be inserted into the changelog for the new commit on the current branch. This is particularly useful if you're creating a new release branch by branching from a previous tag, then grabbing individual revisions from your main development branch. This command became popular among us Pidgin developers while we were preparing the Pidgin 2.5.6 release.

Here's the code:

--[[
  Pluck a revision with the log and authors filled in for the next commit log.

  @author: Sadrul Habib Chowdhury (updated for mtn 0.43 by John Bailey)
--]]

-- pluck-log command
function pluck_log(...)
  local revs = {...}
  local result
  local topsrcdir
  local logfile
  local log

  -- mtn_automate() returns a pair of a boolean and a string; we don't really
  -- care about the boolean here, but we need to do something with it.
  result, topsrcdir = mtn_automate("get_workspace_root")
  topsrcdir = string.gsub(topsrcdir, "\n", "")
  logfile = io.open(topsrcdir .. "/_MTN/log", "r")
  log = ""

  if logfile then
      log = logfile:read("*all")
      logfile:close()
  end

  table.foreach(revs,
      function (index, rev)
          r, sel = mtn_automate("select", rev)

          if r == false then return end

          for rev in sel:gmatch("%S+") do
              r, certs = mtn_automate("certs", rev)

              certs:gsub("%s+key \"(.-)\"\n%s*signature \"(.-)\"\n%s*name \"(.-)\"\n%s*value \"(.-)\"\n%s*trust \"(.-)\"",
                      function(key, sig, name, value, trust)
                          if name == "changelog" then
                              log = log .. "*** Plucked rev " .. rev .. " (" .. key .. "):\n" .. value .. "\n"
                          end
                      end
                  )
              execute("mtn", "pluck", "-r", rev)
          end
      end
  )

  logfile = io.open(topsrcdir .. "/_MTN/log", "w")
  logfile:write(log)
  logfile:close()
end

register_command("pluck-log", "REVISION1 [REVISION2 [...]]", "Pluck a revision with a good log",
      "This plucks a list of revisions, each individually, and adds the changelog of each revision for the next commit log." ..
      "\nEXAMPLE:\tmtn pluck-log h:im.pidgin.pidgin deadbeef\n",
      "pluck_log")

The resulting log entry will look something like this:

*** Plucked rev 074c5aedf9bbc512331f0d3130f076190b290676 (rekkanoryo@pidgin.im):
Set the default pager host to scsa.msg.yahoo.com; this seems to be what the
official client uses.

Originally, Sadrul wrote this code for mtn 0.42 and earlier, which did not have the mtn automate get_workspace_root functionality. I updated the code to call mtn_automate("get_workspace_root") instead of finding the workspace's root with successive checks of parent directories. The revision ID printed in the log was also truncated to the first 8 digits. Ordinarily, this is fine; however, it's possible that in the future a new revision will be created that has the same first 8 digits and thus the short ID will be ambiguous. I wanted to avoid this situation, so I removed the truncation. I also rearranged a few things to make it easier for me to read. I also have to credit my fellow Pidgin developer Elliott with figuring out that I needed to kill the trailing newline in the string returned from mtn_automate("get_workspace_root").

Hopefully we're not the only ones who find this stuff useful. As I make frequent use of other useful monotone lua hacks, I'll probably post about them here too.

Well, as most people have noticed by now, we recently released Pidgin 2.5.6. This release was simply a bug and security fix release. Hopefully it will hold everyone over until we can kick 2.6.0 out the door!

Yesterday, Linux Journal issued a press release announcing the winners of its annual Readers' Choice Awards. It's an annual event that attracts a lot of attention in the magazine. In their effors to "take the pulse of the Linux community," they run this poll and announce the winners and grant honorable mentions to "strong contenders" in the pool of runners-up.

This year, it's been announced that Pidgin has won a Readers' Choice award for Favorite Communications Tool, a category that we're no stranger to winning--we won this same category last year as well. The landscape is similar as well. This year, we won with 42% of the votes, beating out honorable mention Skype, which received 18% of the votes. Last year, we also garnered 42% of the votes, with Skype and Kopete earning honorable mentions at 17.8% and 12.8% respectively.

Winning this award for the second year in a row reminds us that our work is quite well appreciated, something that is often easy to forget. It also reminds us that every once in a while we need to stand back and thank everyone involved in making Pidgin such a popular project. In this case, we need to thank the 2,000+ people who voted for Pidgin in these Readers' Choice Awards, as well as all our developers, Crazy Patch Writers, drive-by contributors who spot a simple bug and fix it, and our users. All of these people in our community come together to make Pidgin a success as a project, and while we'd be just as happy to work on Pidgin if we had only a few hundred users, we certainly appreciate all of the contributions to our success. Thanks!

Well, Google finally announced the list of accepted students for this year's Summer of Code. You can read about our accepted proposals here. Of course, we're all very excited about the projects we've chosen for this year. We have two students returning to us this year, both with projects that will be hugely important moving forward. Those students are Eric Polino and Sulabh Mahajan.

Eric has chosen to work on GObjectification, which will move libpurple from using our own object system to taking advantage of the GObject capabilities of GLib, one of our existing dependencies. As a result of this project, a massive amount of libpurple infrastructure will change, allowing us to leverage a tried and true typing system and giving plugins an incredible amount of increased flexibility by allowing them to subclass objects and providing interfaces they can implement. This will, of course, have huge rammifications for everyone using libpurple--us, plugin authors, Adium's authors, and even the Instantbird authors. We're confident the result will be worth the effort, though.

Sulabh has volunteered to take on the Privacy Rewrite. What makes this such a daunting task is that the protocols we support provide a very wide range of privacy options, some of which are unique. For example, ICQ supports an "invisible" list and a "visible" list in addition to a "block" list and probably a number of other things that I'm forgetting. Sulabh will have to look at what all our protocols support and provide a foundation in libpurple for all the protocol plugins to provide the privacy options their protocol allows for. Additionally, he'll have to smooth over the differences between protocols to make things consistent.

In addition to these projects, we've accepted two proposals for native Windows user interfaces. Each project will take a different approach to achieve the same goal--providing a user interface that fits better into a Windows desktop than Pidgin currently does. I've already seen a few complaints that we accepted two projects for this. Quite frankly, I don't understand the complaints. We chose two projects for two reasons--first, we want to have the highest possible chance to better serve our Windows users, and second, it's entirely possible that a single Windows UI project won't be able to do enough to satisfy all our users. Having two Windows UIs will allow each to focus on whichever set of users it is more appropriate for.

We've also accepted projects that will make XMPP transports based on libpurple, allow libpurple to use telepathy protocol support in addition to or instead of our own, and using webkit for our message displays. Each of these projects is going to be challenging in its own right. Of all the projects, the XMPP transports will certainly be the least user-visible, as the transports will run on an XMPP server. Conversely, the most visible will probably be the webkit message view, as this will completely replace what we currently use to display messages. By using webkit, it's possible that we'll eventually be able to support Adium Message Styles (no, I'm not promising this support will happen, but it will be possible). The Telepathy plugin will provide some interesting functionality by allowing us to use nothing but telepathy for protocol support if the user so chooses.

There are other deeper details in these projects, but I've already wasted too much time obsessing over this post and discussing the larger projects in detail. I'll leave further discussion of the technical merits and details of projects to the students and mentors. Needless to say, this post could have gone on just about forever. ;)

Overall, this Summer of Code looks like it will be one of our best. Good luck to all our students!

Yes, that's right ladies and gentlemen.

PIDGIN NOW HAS VOICE AND VIDEO CHAT SUPPORT!

I doubt much explanation is needed here. Video and voice chat has probably been the most requested Pidgin feature over the past five years.

Many thanks to Maiku, our Summer of Code student from 2008 who tirelessly spent many hours implementing this. This was a huge undertaking. Maiku has told me he will accept compensation in the form of pizzas.

We expect this functionality will be released sometime this month. Stay tuned.

Watch a demo of video chat

Well, once again we've come to the student application phase of Google's Summer of Code program. We're several days into the process, and we've seen a marked decrease in our intake of student applications compared to prior years. Why is anybody's guess, but I'm personally hoping it means that potential applicants are spending more time polishing their applications before submitting.

Based on the applications we've seen so far, I'd like to publicize a few notes for applicants:

• Provide a detailed timeline for your project. "I expect to complete work in 10 weeks" doesn't cut it here. Tell us what milestones you expect to achieve and how far along. You could instead estimate how long a specific goal will take to implement. Yes, your estimate could ultimately prove wrong, but that's not necessarily the end of the world. We really want to see that you have a concept of time management and prioritization.
  
• Don't plagiarize. If we know you're plagiarizing, we'll invalidate your application. If you can't deliver an application without plagiarizing, you shouldn't be applying. We don't mind if you use some of the text on our ideas page to help with the abstract, but keep in mind that a serious application won't rely on simply copying and reformatting what we've already said.
  
• Don't be afraid to come up with a unique idea! The ideas page are not the only ideas we'll entertain. We love to see well thought-out, original ideas, especially ones that make us wonder why no one proposed it before.
• Make sure your proposal is for a specific project idea. A general "I want to work with Pidgin for the summer" is a sure ticket to the reject bin.
• You don't have to write an encyclopedia for the application, but you do have to give us something to work with. There's an old adage that "less is more." Sometimes that's true. Sometimes the opposite is true. The point here is that you should be verbose enough to explain your idea, but don't ramble. I know this can be difficult to judge. Just re-read the application, make sure it makes sense, and make sure it doesn't drag on needlessly.
• You have to apply using the SoC webapp, not our mailing lists. We have to have applications submitted via the SoC webapp in order to review them and have them in the running for our student slots. This is a Google thing, and it makes everyone's lives a lot easier.
• The application isn't final until submissions close. We will provide feedback on your application if it needs work. You can modify your application to address our feedback until applications close. Use this to your advantage!
• We don't yet know who will mentor any given project. We don't assign final mentors and backup mentors to projects until we have decided which projects we want to accept. Asking us about this is just wasting your time.
• We expect you to treat the project as a full-time job. That means at least 35 hours per week. We want to make sure everyone gets the most out of Google's money, and this is one way to do that. Since you'll technically be a contract worker, we expect the contracted work (your project) to take priority.
  
• We expect you to remain actively involved with us after the Summer of Code finishes. Quite frankly, if you're going to collect the checks and run, you're missing the entire point. The Summer of Code is intended to attract new contributors and get them involved in open source software, turning them into long-term contributors. Participating in the Summer of Code and then disappearing isn't serving that intention, and leaving us with code we have to maintain ourselves is quite rude. If that's your intention, please don't apply. Let the potential for acceptance go to someone who will stay with us.
  

Keep these in mind, and happy applying!

A number of minor problems have been fixed in this new release. If you've been having problems, upgrade and hopefully they will be gone.

The download and list of changes can be found at www.pidgin.im

From my limited experience with Pidgin users among my family and coworkers, I've discovered that a number of users don't know about Pidgin's saved status features and instead use only the transient statuses created directly in the status selector by typing a message. Some users don't even realize that they can select a previously used transient status from the middle section of the status selector's menu. As an attempt to spread deeper insight into Pidgin, I submit for your reading this saved status tutorial.

Overview of Saved Statuses

In Pidgin, a saved status gives you a considerable amount of flexibility. For example, if you use six accounts, three of which are personal and three of which are for work, you can use a saved status to have your work accounts away while your personal accounts are available and vice-versa. Or, if the text box you get from using the status selector irritates you, you can use saved statuses to get rid of it forever.

Creating a Simple Saved Status

Let's start with two basic saved statuses--one Available status and one Away status.

Click the status selector at the bottom of the buddy list window. You should see something like this:


Select the "New status..." entry. You should see something similar to this:


The fields here should be pretty obvious and self-explanatory. The title will be what you see in the status selector menu. Generally, I use a descriptive title, such as "Away - Sleeping" or "Available - no message," that will quickly identify the message's contents to me without needing to read the message. For this example, I'll use "Away - example."

For Status, obviously you want to choose one of the basic statuses listed--Available, Away, Invisible, Extended Away, Offline, Do Not Disturb, or Invisible. If you use only one account, your choices could be significantly different. For this example, we'll accept the default of Away.

in the Message box, type your status message. For my example Away status, I'll use the message "Away for the sake of being away."

Click Save. Alternatively, if you want to use this status now, click "Save & Use." You could also click "Use," but then the status would not be saved.

Now, repeat the process for an Available status. In this example, I'll have a title of "Available - no message", a status of Available, and a blank message.

Now, if you select "Saved statuses..." from the buddy list window, you should see something like this, but probably with a lot fewer statuses listed:


Creating a Complex Saved Status

A complex saved status is where the real power of saved statuses becomes obvious. Let's modify the existing away example we created. Select it in the saved status list and click "Modify..." Now click the expander just to the side of "Use a different status for some accounts" and observe the list of accounts that appears.

Put a checkbox in one of your accounts. For this example, I'll use my pidgin.im XMPP account. Now you see a much simpler new dialog:


For simplicity's sake in this example, I will choose "Extended away" as the status and use "test" as my message. After clicking OK, I return to the modify status dialog, to see something similar to this:


Now you can click "Save" or "Save & Use." This gives you essentially the simplest form of complex status--one in which only one account differs in status from the other accounts. Using this status will cause all but that one account to appear as away, and cause that one specific account to appear as extended away (note the clock vs. the circular sticky note).

Using a Saved Status

To use a saved status, you can select it in the status selector's menu if it's listed. If it's not listed, simply click "Saved statuses..." in the status selector to bring up the Saved Statuses dialog, then select the status you want and click "Use." The status should now be remembered in the "popular statuses" (middle) area of the status selector menu. Of course, with disuse or use of a large number of statuses, a given saved status can fall out of the saved statuses list, in which case you'll need to repeat the process of finding it again. If you use the statuses a lot, though, this won't be a problem.

Practical Applications

Saved statuses aren't for everyone, of course. They do provide a number of possible complex status combinations limited only by the number of accounts you have in Pidgin. They also let you get rid of the ugly text box for status messages for as long as you use saved statuses. They also offer a relatively quick setup time that allows you to create your status once and use it as many times as you want without ever having to think about how to configure the status again.

Enjoy playing with your newfound saved statuses!

Well, by now probably everyone's aware that our (Pidgin's) sites had been down for several days. Here's the basic rundown of what's happened with our servers over the last couple years.

Prior to our going public with our rename, Luke Schierer secured a donation of a virtual server from DVLabs. This server was intended to enable us to migrate away from SourceForge's web platform and tracker. It allowed us to have our own domains, and thus host and control our own e-mail services, mailing lists, and Trac. This server did its job for us quite well, even though we did occasionally push the server to or beyond its limits. (Note that in these instances real hardware would actually not have made a noticable difference at all, as all the resources of the real hardware would have been utilized just as we had experienced in the virtual machine.)

Even though we were extremely grateful to DVLabs for providing us a server, we did realize that having only a single server presented us with some limitations, the most important of which is "graceful" failure of core services if the server goes down. It also presented a single point of failure in that the web server getting pounded (such as a posting to Slashdot causes) could potentially cause all our services, including monotone and mail, to grind to a halt. Because of this we had tossed around the idea of finding another host two or three times.

When we most recently thought about hosting, Evan Schoenberg from the Adium project (who also happens to be a libpurple developer) put us in contact with NetworkRedux, who generously provides Adium's hosting. Thanks to Evan's intervention, we spoke with NetworkRedux about our hosting, and they were willing to donate not just one, but two servers and a ton of bandwidth to our project. Thanks to NetworkRedux's generous offer, we're getting the potential to have a lot more raw computing power at our disposal (including more memory to help increase caches, thus hopefully improving speed), as well as the ability to spread our services out a little so that a heavy hit to the website or to trac won't have a detrimental effect on all our services.

We were still discussing details of migrating to these two new servers when the server at DVLabs unexpectedly went down. It turns out that some miscommunication and bad timing caused the guys at DVLabs, who were migrating their own stuff, to down the server hosting our virtual machine, thinking we were no longer using it. We were, of course, confused at first, but once we determined what was happening we were much more at ease. None of our data had been lost. DVLabs were kind enough to supply us with the raw VM image for our own use to recover our data and complete our migration.

From these events we have learned a lesson--redundancy is not only good, it's pretty much a must-have. In the interests of redundancy and graceful failover, we've taken some steps to help prevent future long-term outages. One of those steps is that Gary Kramlich and I decided that we would help out by providing some service redundancy on our server, guifications.org. The biggest, and most important, service we are helping with is monotone. If for some reason the monotone server is down, guifications.org can seamlessly stand in for the mtn.pidgin.im server through the magic of DNS. We're also looking at potentially acting as a backup for more services.

So all in all, the commotion about our sites being down was really just a lot of noise about nothing truly significant. Yes, our sites were down, but this wasn't the end of the world. Google's massive cache had pretty much all the critical information anyone could need from our wiki. Yes, monotone was down, but guifications.org was ready to help--I had been running a read-only mirror for nearly a year which was ready and able to stand in as a production service if needed. Our mailing lists were down as well, but again, it wasn't the end of the world. Overall, we have weathered a prolonged service outage pretty well and taken some lessons from it to help us in the future.

In closing, I would like to extend my deepest, most heartfelt thanks on behalf of all Pidgin developers to DVLabs for their hosting services over the past two years and to NetworkRedux for the services they are now providing for us. We truly appreciate these donations!