bzr speeding up Bitlbee development?

meta = {'category': bazaar, 'date': Wed 14 December 2005}

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
• 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 ancestry graph of my integration branch is getting more and more complex every day.

comments.

BitlBee 1.0!

meta = {'category': bitlbee, 'date': Sun 04 December 2005}

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 a formal release speech from Sjoerd (a blessed Bitlbee tradition) and pizza. I took some photos.

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

comments.

BitlBee officially in bzr now

meta = {'category': bitlbee, 'date': Tue 15 November 2005}

Wilmer announced the switch of Bitlbee’s source control system to bzr yesterday, so it’s finally official. This will hopefully make it easier for Maurits and me to contribute, and increase the number of external contributors.

comments.

trac hook for bzr

meta = {'category': bazaar, 'date': Wed 09 November 2005}

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.

comments.

bzr for BitlBee

meta = {'category': bitlbee, 'date': Tue 08 November 2005}

After three years without, it looks like BitlBee is finally going to leave the dark ages and use a version control system that was not thought up in Wilmers’ basement. Up until now, Wilmer kept a master copy of the tree from which he generated nightly snapshots. The other two developers (Maurits and me) would then send patches against those nightly snapshots which Wilmer would apply. This sort of worked, but it wasn’t 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, 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 these limitations.

We’re probably going with trac+darcs for the new bug tracking system.

comments.

1.0… at last?

meta = {'category': bitlbee, 'date': Tue 01 November 2005}

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.

comments.

BitlBee Bughunting sessions

meta = {'category': bitlbee, 'date': Fri 03 June 2005}

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.

comments.

Interview with BitlBee developers

meta = {'category': bitlbee, 'date': Tue 12 October 2004}

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

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

comments.

Win32 Testing server running

meta = {'category': bitlbee, 'date': Wed 15 September 2004}

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.

comments.