Right. So I finally took some time and energy from other stuff (sports, enjoying the air, juggling, playing with Blender, working for clients, and so on) and spent a few hours getting back in touch with Gforge development.
First, now that my contract with Tim Perdue of the Gforge Group is done, I'm allowed to release my work to the general public. I therefore present you gforge-plugin-scmsvn, gforge-plugin-ldapextauth, and gforge-plugin-scmccase. The first is the much-awaited support for Subversion as an SCM for Gforge (in addition to CVS), the second is the code allowing to delegate authentication to an external LDAP directory, the third one is for Clear Case (and you don't want to use it). These three plugins have been committed to the gforge.org CVS (available at :pserver:firstname.lastname@example.org:/cvsroot/gforge if you want to check them out), and I uploaded them to my unofficial apt repository. Feel free to fix bugs in them, and send patches.
Then, Gforge proper. It's been weeks (months?) since I last followed Gforge upstream development, so I had to get back in touch, see what had changed, that sort of thing. Especially since Sarge is near, at some point after that I'll have to upload the new Gforge upstream releases to Sid (or experimental, at least).
Well, uuuurgh. It seems people have been evil while I was away.
My Perl script for reliable database upgrades has been perverted to call an external PHP script, without checking for its results, then happily proceed to whatever is next on the upgrade task list. So the table that reliably said "the database is now using version <foo> of the schema, which means all operations to upgrade to it have succeeded" now says "the database is now using version <foo> of the schema" even though some unspecified operations have failed, or been ignored, or forgotten, or whatever. Yay for dependability.
It's frightening enough already, but while I was investigating the need for that PHP script, I discovered that it's used to rename the forums. Yay. [0-9a-z_-] only from now on, no other characters. Bye bye i18n, bye bye user choice, bye bye user friendliness. I call that a regression. Imagine you have a forum named フォーラム, it'll be automagically be renamed to ----- (or maybe even ---------------, I didn't check). Lovely, eh?
Ah, but there was a reason for this renaming, wasn't there? Oh yes, there was: the forums now have email addresses. So the posts that are sent to you when you monitor them come From: Joe Bloggs <email@example.com>. Nice. So now BBDB asks me whether it should remember that address as a new address for Joe Bloggs everytime I read a post. And I assume there will be a problem when Joe Sixpack, who also posts to the forum, ends up with the same email address.
And why do the forums have email addresses? Presumably because you'd want to post to them by email! So what's the point of having users and passwords, if anyon can post under anyone's name? I'm even told there is similar evilness in the trackers (where anyone can post anything to any tracker simply by forging email headers). Hah.
And I fear there are other "tricks" along these lines in all the code I haven't had a look at, or heard about, yet.
So I assume people shouldn't expect too much of Gforge 4.0. Either I manage to get the release delayed until after things have been unbroken, in which case 4.0 won't be out for a couple of months, or I don't, and 4.0 will be crappy. This applies to both upstream Gforge and the Debian packages for it. In other words: every help is welcome for the packaging, because I fear this is going to end up in an ugly mess.
On a more positive note: Wichert Akkerman has been working on a replacement for our LDAP setup, whereby both Exim/Postfix and PAM/NSS would use the database directly rather than an intermediate LDAP directory. If/when that comes out, that's going to get us rid of the single most troublesome part of the packaging. So yay for him!