Death of a thousand tickets

Well, by now it's obvious to the world that I kicked Pidgin 2.7.4 out of the nest last week. Although that release included some nice new features for ICQ users, lots of bug fixes, and some remote crash fixes, it's not without its share of problems. Those problems are producing a bunch of duplicate tickets for us to deal with, so I thought it might be a good idea to post about them here just in case anyone bothers to read my rambling.

The first problem is the AIM/ICQ chat bug. When using a multi-user chat on AIM or ICQ, no messages can be sent. You'll get an error stating your message was too long. This was an unintended side effect of merging the work of one of our Summer of Code students. Ivan accidentally removed a line of code that he shouldn't have. Yes, you read that right--a single line of code. Apparently it was pretty important! Ivan restored that line and things will be working as they should in 2.7.5 when we release it.

The second problem is an old one that's come back with a vengeance. This one is an ICQ issue where messages that contain <> disappear because they're treated as HTML tags. This seems to be specific to combinations of Pidgin and other non-official clients. Pidgin recently gained some new ICQ protocol-level features related to formatted messages; some non-official clients, including older versions of Pidgin, don't handle it gracefully. At this point, we've done all we can do about it; the other clients will have to step up and make fixes to handle the messages correctly now.

The next problem is another wonderful ICQ encoding bug. I'm not sure if this one is a side effect of Ivan's work or not, but Ivan did do a lot of work on encoding problems on ICQ. We all thought things were improving, but apparently there are still a few odd cases (and a crapton of stupid ICQ clients that should be purged from existence) in which our handling of encodings just isn't quite right. We're aiming to have this fixed for 2.7.5, but it's not quite done yet.

Is it obvious I wish ICQ would just disappear immediately and permanently?

The last "big" problem that seems to be cropping up is a crash related to MSN file transfers. When using direct-connect file transfers, somewhere along the line we do something stupid internally that causes a crash. We thought we had it fixed for 2.7.4, but alas it still exists. We're looking into it and hope to get it fixed soon. In the meantime, it's pretty easy to prevent the crash--edit your MSN account and turn off the direct-connect file transfers. It's an option on the advanced tab of the account editor.

At any rate, since we know about these bugs already, please, please, please DON'T open new tickets about them!

The Proxy Conundrum

As many of you Yahoo users out there know, Pidgin 2.7.0 and 2.7.1 introduced a challenge for you. In certain proxied environments, many of you can't connect. Quite frankly, (mostly) it's my fault. Let's start by explaining what I've done.

In Pidgin 2.7.0 I made some seemingly innocent changes to the Yahoo protocol plugin that I thought would magically make some problems go away. These changes make us mimic the official Yahoo client better. Very early in the connection process (in fact, it's the first step), the official clients request a specific URL from a Yahoo web server. The server's response tells the client what messaging server to connect to. The client reads that address and connects to it, then goes along its merry way. So I made our Yahoo plugins do this, once I determined the correct URL's for both Yahoo and Yahoo Japan. Everything was great when I tested.

But there's my mistake--I tested it. I don't run a proxy server--I'm an IT nerd, but I'm not that much of an IT nerd. So, I allowed this to be released, not knowing there were problems in environments with restrictive proxies. It came back to bite me hard, as I backported this stuff to Adium's build of libpurple 2.6.something for one of their beta releases and several users started complaining about being unable to connect. Then we got a couple tickets of our own. At first, I was stumped, until a user who was willing to almost bend over backwards to assist us came along.

This user worked in an environment where two separate proxy servers were in use. One handled HTTP and HTTPS traffic and the other handled IM protocols. It took me quite a while to finally wrap my head around his problem, but once I did (with the help of my fellow developer Etan Reisner), I was able to start solving the problem. It turns out I actually had two problems on my hands, but at first it seemed like none of it was the fault of our code.

The first problem is that Pidgin allows configuring proxies in two places--the "Proxy" tab shown when editing an account and the "Proxy" tab in Preferences--but does not allow specifying what ports or services are handled by each proxy. This ordinarily isn't such a big issue, except that I went to the extreme of creating an option for Yahoo accounts to help some users with weird proxies that don't handle SSL at all. This option is used to determine whether to send an HTTPS request (like Yahoo uses for login) to the account's configured proxy or to the global proxy configured in Preferences. When I did this for 2.6.0, I created a new utility function for URL requests that allowed specifying the account the request was for. If the magic value NULL is passed to this function, the request will use the global proxy instead of the account proxy. This allows our proxy code to route the request to the appropriate proxy. Being the idiot I can be on occasion, I set all URL requests in the Yahoo plugins to use the account proxy server no matter what. This is where the user's problem came in--his IM proxy doesn't do HTTP at all. Once Etan and I agreed on how to fix it, I changed the SSL option I mentioned earlier to act on both HTTP and HTTPS requests. I supplied our user the test build. It still didn't work, but the debug log showed some interesting new info.

Again, it took some head-bashing to understand what was going on, and I still wasn't the one who figured it out. In the meantime, I decided to implement a quick hack to make users at least be able to connect temporarily while we figured out what was really broken in our proxy code. The quick hack was to implement a worst-case, last-resort connection to a previously known messaging server. Unfortunately, I could implement this only for Yahoo, not for Yahoo Japan, as the Japan network appears to no longer has a single canonical hostname by which to refer to the messaging servers. I am, however, positive that even on the regular Yahoo network, this hack will eventually break, which is why I resisted it in the first place. After a couple quick bugfixes brought to light by the user's further testing, we had a working fallback mechanism.

Once this was done, Daniel Atallah, one of our co-lead developers, realized that the second problem our helpful user had was our own proxy code's fault--for some stupid reason, we would never authenticate to an HTTP proxy if we were making an HTTP request on the standard HTTP port (80). Daniel implemented some quick fixes to make our URL requesting code behave better in these proxy situations, thus (we hope) finally solving this problem completely.

All these fixes will end up in Pidgin 2.7.2. We're not sure yet when we're going to release that, but we're hoping it's soon, as we have some fixes for other annoying bugs, such as the famous MSN direct connection crash.

Now, after reading all this, some of you might think, "Why don't they just use libproxy?" Truthfully, that's probably a good idea. There are two reasons we haven't done this yet. First, we looked at this over two years ago. At that time, we were led to believe libproxy didn't handle all the proxy types we did. We were corrected on that, but I, at least, missed that correction being posted. (Sorry, sometimes I'm blind, especially if something like that is buried in a flood of other ticket mails.) I suspect I'm not the only developer who did. Secondly, we're all creatures of habit. As the old saying goes, "if it ain't broke, don't fix it." Well, quite honestly, it's not broken for us as developers! Mainly that's because either we don't use proxies or any proxies in our way don't do any of the crazy stuff we ran into in this case. If it's not broken for us, we don't have much incentive to go hacking stuff up to support new libraries that solve problems we don't experience. I know that sounds like a lame excuse to a lot of you, and I can understand how it seems that way. But if we don't experience the problem, it's hard to test that we've fixed it, and we could in fact be making matters far worse for everyone else.

All this said, we probably should support libproxy. I've been thinking about how we could do this in a quick and effective manner, and so far I've come up with a few ideas that don't feel like they work very well. I think this is a perfect case where code should talk, or at least provide an example. So, I invite people who would like to see us support libproxy to write patches. Actively engage us on our development mailing list (devel@pidgin.im), talk with us in #pidgin on irc.freenode.net, or drop by our XMPP MUC (devel@conference.pidgin.im). Or, do some combination of the three. I can't promise we'll be the most valuable resources during the process, but we do at least try.

Now supporting libproxy is one thing. Actually being able to do useful stuff with the information libproxy gives us is another thing entirely. Our actual proxy connection code is, shall we say, a bit sub-par. Quite frankly, it sucks, even ignoring the crappy configuration portions. While supporting libproxy is nice and may solve a lot of our proxy problems, I guarantee it won't solve them all. Ideas and patches to fix this are greatly appreciated too.

I look forward to hearing from those of you inclined to help!

Pidgin 2.7.0: Movin' on Up

Well, I finally managed to kick Pidgin 2.7.0 out the door, as most of you are surely aware of by now. There are several important things to note about this release:

• AIM and ICQ clientLogin issues have been resolved. You should be able to now use both clientLogin and SSL together.
• Our internal libgadu has been upgraded from something from the stone age to something much, much more current. This solves the issues that (primarily) Windows users had with not being able to communicate with new (> 17,000,000) Gadu-Gadu numbers.
• Our Yahoo and Yahoo Japan plugins now retrieve connect server information directly from Yahoo, just like the official clients do. This took me way too much time to implement, but I believe I've implemented a fairly stable and maintainable method to retrieve this information. During this process, I learned a lot about how Yahoo's authentication works and made some improvements there too that will make us look much more like the official client on the wire during authentication.
• ICQ now has X-Status support! It took far longer than it should have--I originally wanted this in for 2.6.0 but it was nowhere near ready.
• Minimum GTK+ and GLib requirements are now 2.10.0 and 2.12.0, respectively. This allowed us to drop some 3800 lines of code, much of which was the result of needing to bundle certain GTK+ widgets so Pidgin could function on platforms with ancient GTK+. This also makes use of many of glib's convenience functions much more convenient.
• The Windows installers have changed to be less obnoxious with respect to GTK+. We no longer install a system-wide copy of GTK+ and instead install GTK+ locally to the Pidgin installation. This may disrupt some GTK+ theming. The other big thing is that now, the default installer will download GTK+ and optionally the debug symbols (so there's no longer a special debug installer needed for crash reports!). There's also an offline installer that, while almost double the size of the default installer, I prefer to use. This offline installer includes GTK+ and the debug symbols. I prefer to call it the everything-but-the-kitchen-sink package (the kitchen sink in this case being spell checking support, which still must be downloaded).
  

Of course, any release I had a major role in is bound to have problems. I built the Windows installers this time around, and did not know that I needed to do extra work to make the online installer function. Thus, many of you complained (and complained, and complained some more!) that the installer didn't work. Even after Daniel fixed this for me, we still saw complaints. If the online installer does not work for you, try the offline installer. I tested the offline installer and it worked for me. I forgot, however, to test the online installer. I was more interested in getting the release out in order to (I thought) minimize complaints.

Additionally, after I cut the tarballs for 2.7.0, several bug fixes rolled in that will be delayed until 2.7.1. Among these are a couple minor annoyance fixes for MSN and XMPP. And today fixes for more bugs rolled in, including two for Bonjour and a fix for the taskbar entry (window) flashing on Windows. I plan to push out Pidgin 2.7.1 in a couple weeks to resolve these, and hopefully more, problems.

In the mean time, enjoy!

Plugin Authors: Save Your Users' Sanity!

OK, maybe I'm being a bit sensationalist there, but it's my blog, so I'm allowed! Anyway, on to the subject matter.

Recently we've seen a few users in #pidgin (and I've received some emails too) with some strange issues that result from plugins doing things they really shouldn't but can anyway. I'm going to run down a small punch list of items for you, as plugin authors, to do to prevent your users having hard-to-diagnose issues.

• Never use printf() in a plugin. This causes terminal disruption for Finch users and is a bad idea in general. It will probably behave unpredictably on Windows and/or in other UI's too. We provide a debugging API to avoid this kind of stuff. Instead of printf(), use purple_debug_info() or purple_debug_misc(). You can see the debug output (even during initial startup) if you run 'pidgin -d', even on Windows and even if your Pidgin is built without '--enable-debug'. For Finch, you can do 'finch -d 2> finch_debug.txt' to get your debug info.
• Don't lie about UI requirements. If you use GTK+, you're a Pidgin plugin, not a "core" (or libpurple) plugin. If you use GNT (or if you're really brave and use ncurses directly), you're a Finch plugin. There are plenty of examples in the Pidgin and Purple Plugin Pack source trees that show you how to properly declare your UI dependency. The UI requirement is designed specifically so that plugins requiring a specific UI can't be loaded by, and thus cause problems for, other UI's. Sure, it's possible to make a UI-agnostic plugin that requires GTK+, but I guarantee it will cause at least one or two Finch users unnecessary problems.
  
• Install your binaries to the correct place. If you're installing a Pidgin plugin, install to $prefix/lib/pidgin, not $prefix/lib/purple-2. If you're installing a Finch plugin, install to $prefix/lib/finch. This will prevent other UI's from needlessly trying to probe your plugin and is just general courtesy. (Note that this particular item doesn't apply to plugins for Pidgin on Windows at the moment, but may be important later.)
• If your plugin is a protocol plugin, you absolutely are not allowed to touch UI-specific code at all. That means no GTK+, no GNT, no XUL, etc. If you need UI elements, use the request API libpurple provides. If the request API doesn't cut it, there are other approaches you can take, such as having two plugins, one of which does the actual protocol work and the other providing the UI. A better approach, though, is helping us identify where the request API is lacking so we can improve it. We know our API's aren't perfect, so when someone can show us a concrete reason why we're deficient, we will try to fix that deficiency.

Please check your plugins for these problems and help your users have a more pleasant experience with your plugins!

Time flies...

It feels like it's been forever since I stepped up on the soapbox to say something. This time it's just a relatively short update.

As is very commonly known, Pidgin was accepted as a mentoring organization for the Google Summer of Code again this year. This year, Google has given us the privilege of mentoring four students. While less than we hoped for (we'd wanted five), we certainly can't complain about the projects we were able to accept.

First up is an MSN project manned by Jorge Villasenor Salinas, who some may recognize as having helped implement custom emoticon support for Pidgin 2.5.0. His project is to rewrite the SLP layer of the MSN plugin, simplify the other parts of the plugin, and overall make the plugin much easier to maintain and extend. I'm sure he'll be trying to squeeze some new features into his project if time allows.

Next up is one of my personal favorite projects for this year. Gilles Bedel will be working on detachable sessions. This is something a number of us have wanted for a long time, but just haven't quite gotten around to making it happen. The idea here is that we can have a daemon (service for the Windows-inclined among us) running in the background and connect to it with Pidgin or Finch at will. I feel that this is perhaps the most ambitious project this year, but the benefits it could reap are worth it.

Adam Fowler is going to rewrite the log viewer in Pidgin. This particular project will likely be the only project that visibly changes Pidgin this year. We've received a lot of complaints and suggestions over the years focusing on our log viewer. We know it's deficient in a lot of ways, and that's what Adam's project aims to resolve. I'm confident we'll get a lot of positive feedback about this project once it's complete.

And last, but not least, is Ivan Komarov's ICQ project. Ivan's aim is to beat our ICQ implementation into shape. As most of our non-US ICQ users can confirm, our interaction with the service could use some improvements. While Ivan has proposed a nice wide range of things to fix, even just a few of them being completed would make a huge difference for our international users.

So, from all of us developers, and we hope from our users too, good luck to our students!

On The Subject of Bugs, or Help Wanted and Needed!

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!