Stationary Traveller - bitlbee

bzr speeding up Bitlbee development?

nospam@example.com (Jelmer Vernooij) — Wed, 14 Dec 2005 14:05:04 +0000

Now that we've switched to a version control system for Bitlbee, the development activity is suddenly reviving. The fact that 1.0 has now been released was certainly also a reason for the large number of commits in the past weeks, as previously we were mainly aiming at improving the stability of Bitlbee.

Some of the things that have been merged into the main tree over the past week or so are:

- groupchat support in oscar by Nelson Elhage's
- typing notification improvements by f0rked
- new storage abstraction layer by me
- support for plugins by me

and lots of smaller improvements, mainly by Wilmer

The [/blog/uploads/integration.svg ancestry graph] of my integration branch is getting more and more complex every day.

BitlBee 1.0!

nospam@example.com (Jelmer Vernooij) — Sun, 04 Dec 2005 19:42:04 +0000

It took us almost 3.5 years, but at last we managed to reach the important milestone: Bitlbee 1.0 is now officially released! We held a small release party in Utrecht this afternoon, including release speech (a Bitlbee tradition) and pizza. I made some photos.

Bigger challenges await us now as we continue to cleanup the various protocol implementations and start working on 1.1 and 2.0.

BitlBee officially in bzr now

nospam@example.com (Jelmer Vernooij) — Tue, 15 Nov 2005 13:46:17 +0000

Wilmer announced the switch of Bitlbee's source control system to bzr yesterday, so it's finally official now. This'll hopefully make it easier for Maurits and me to do development as well as increase the number of contributors.

trac hook for bzr

nospam@example.com (Jelmer Vernooij) — Wed, 09 Nov 2005 14:50:12 +0000

Since we'll be using trac as the bug tracking system for BitlBee and bzr for source control, we won't be able to use the default post-commit-message-hook, which comes with trac. This script usually makes sure that whenever a commit is done that references a bug, this gets mentioned on the page of that particular bug in trac.

I've hacked up a quick plugin for bzr which implements the same thing for the combination of bzr and trac. This isn't the ideal solution since it requires that the script is running on the same host as the trac server, which is sometimes not the case as people push changes to their server rather then log in to their server and merge and commit the changes from their workstation.

The proper fix is probably getting trac itself to get information like this from the commit messages. It already detects new commits (they are shown in Timeline) and knows how to parse them, so something like that shouldn't be very hard to implement.

bzr for BitlBee

nospam@example.com (Jelmer Vernooij) — Tue, 08 Nov 2005 11:36:01 +0000

After three years without, it looks like BitlBee is finally going to be managed using a version control system ! :-) Up until now, Wilmer kept a master copy of the tree from which he generated nightly
snapshots. The other developers (Maurits and me) would then send patches against those nightly snapshots which Wilmer would apply. This situation worked, but it wasn't really ideal: migrating in-progress patches from snapshot to snapshot takes a lot of time and creating incremental patches can be impractical as well.

Some of the objections Wilmer had against using a version control system, in particular CVS and Subversion (which I was originally trying to sell him) were the fact that they require a manual 'svn add' for all files you create and a 'svn rm' for files you delete and the requirement for setting up a special server. At the moment, we're experimenting with bzr since it doesn't have many of these limitations.

We're probably going with trac+darcs as the new bug tracking system.

1.0... at last?

nospam@example.com (Jelmer Vernooij) — Tue, 01 Nov 2005 18:21:46 +0000

Doing a bit of BitlBee development again during the last few days. Wilmer released 0.93 yesterday, and we've hopefully now also tracked down the bloody 100% CPU usage bug we have been chasing for the past 6 months. That's the last bit on the roadmap to the big 1.0 release.

I've also started on rewriting the Windows port of BitlBee as a service rather then as a user program. The current version was rather unstable, mostly because it had to deal with a GUI thread and BitlBee's core thread which is not really written with threads in mind.

The Win32 branch is available at win32.bitlbee.org.

BitlBee Bughunting sessions

nospam@example.com (Jelmer Vernooij) — Fri, 03 Jun 2005 20:57:58 +0000

We held a bit of a BitlBee coding marathon yesterday evening, with all three main coders (Wilmer, Maurits and me) involved. We got a couple of minor bugs fixed, nothing big.

People keep asking us when we (or rather, Wilmer :-), will release 1.0. That question is easy to answer: we'll release when all known major bugs in BitlBee have been fixed. There's still a rather major bug in the current development snapshots that very rarely causes BitlBee to suddenly loop and eat CPU. Unfortunately, this bug is hard to reproduce (it takes several days on a heavily used server like testing.bitlbee.org). We'll track it down eventually, I'm sure, but it'll probably take another couple of weeks.

Interview with BitlBee developers

nospam@example.com (Jelmer Vernooij) — Tue, 12 Oct 2004 14:57:12 +0000

LinuxReviews has interviewed
my fellow BitlBee developers and me. Interview available
here.

*(Update 16:55)* Slashdot has a post about the interview as well.

... And thanks to xiando for not losing his patience ;-).

Win32 Testing server running

nospam@example.com (Jelmer Vernooij) — Wed, 15 Sep 2004 16:53:12 +0000

Now that the last few bugs in the win32 version of Bitlbee have been fixed,
I have brought up a public test server. Point your IRC client at
win32.bitlbee.org:6667 and try it!

The test server is running the 9 Sept snapshot on NT4 inside of VMware.