how well supported is Trac-Bzr?

> Martin, do you work for Canonical?

No. Haven't been offered a job (yet), haven't asked for one, and I'm not sure I'd find the time for even a part-time contract.

> Have they assigned you to work on Trac-Bzr?

No.

> For how much of your time?

I'm working on trac-bzr in my free time. How much time that actually is varies a lot. Fixing minor things usually works within a reasonable timeframe, but major problems or new features might take more time. The rewrite to introduce caching in particular has been on my mind for quite some time now, but will require a lot more free time than I currently have.

> What is the overall level of commitment to and/or interest in Trac-Bzr there?

I've got my own trac-bzr setup deployed, and getting that to work was my initial reason for working on the codebase. The fact that I was told I could simply commit to the codebase without too much trouble with reviews and such encouraged me to continue working on it. http://irclogs.ubuntu.com/2009/11/19/%23bzr.html#t15:39 might be interesting reading here.

As long as my setup works, other people's bugs have lower priority than my own job, although I try to make an effort fixing them nevertheless, sonner or later.

> Are other people actively working on it?

Jelmer created a branch recently, to work on bug #120470, but according to http://irclogs.ubuntu.com/2009/11/19/%23bzr.html#t20:09 he no longer feels involved - or at least didn't at that time. I recieve useful input from various people from time to time, but nothing I'd consider an ongoing involvement in the actual codebase. So I'd say no.

If anyone wants to help out, I'd be glad to give him a tour of the code. For someone actively working on the code, I've found the #bzr channel on freenode pretty helpful, although most people there don't know trac internals too well.

> In other words, can I count on Trac-Bzr still being usable for some while into the future?

As usable as it is now, I should think yes. Trac changes somewhat between its revisions, but trac-bzr isn't too complex, so it's usually simple enough to adjust. If either trac or bzr should change their API dramatically, or if you are looking for some kind of new feature or performance improvement, then honestly I don't know.

So I'd basically base my choice on what kind of project you are thinking about, how much you'll have to care for scaleability. If you expect some thousand commits, including sidelines, then it should be all right. If you expect tens of thousands of commits, then I'd worry about scaleability and perhaps try to find someone helping me implement caching.

If there is interest, I could think about ways people could offer money to sponsor the resolution of certain bugs. That would increase my chances of tackling them even if spare time is short, and would decrease my chances of abandoning trac-bzr development altogether.