For a while I was the main server developer. See also the MusicBrainz "Bio" page, and my home page.

However it's been a while now since I seriously hacked on the server (late 2004 I think it was) - these days I tend mainly to do whatever's necessary to keep things running smoothly and to keep the service available, rather than hacking on new features or bug fixes.

On the main site and IRC, known as djce

Things I'm working on, or would like to work on

Server Set-Up

See /UbuntuSetup

Replication

The fun bit: moved to ReplicationRevampFeature.

Other Replication Changes

• We could probably do with changing the filesystem structure of replication packets, so that we get smaller directories
  • old: sprintf "pub/musicbrainz/data/replication/replication-%d.tar.bz2", $SEQ
    • starts to get iffy after, say, 10000 hours (approx 14 months)

• • new: sprintf "pub/musicbrainz/data/replication/%d/replication-%d.tar.bz2", int($SEQ/1000), $SEQ
    • starts to get iffy after approx 1000 times that (over 1000 years)

• • Impact:
    • Needs new code, both at the master site and all the slaves. A whole release almost seems like overkill... maybe commit the change to the release branch, update the master, and ask the slaves to do an "svn update" at their end? Either way it'll need to be announced via mb-datafeed beforehand.
    • Will cause a "spike" when next mirroring to OSL@OSU. Still, it's a smaller spike than our twice-weekly full exports.

• In general: replication slave "with hooks"
  • make it easier to run a replication slave with "hooks" for doing "stuff" with the changes
  • should be possible to use either a near-real-time feed, or the packets
  • would need hooks for "row inserted", "row updated", "row deleted"
  • if the slave could be divorced from a SQL database, would also need a hook to read (the non-SQL equivalent of) replication_control

User Email Verification

Moved to EmailVerificationFeature.

Message Board

See http://bugs.musicbrainz.org/ticket/3583

Regarding deletion: ideally if a user's email expires (see EmailVerificationFeature), then they log in > 1 year later, it would be nice if the message telling them about the expiry was still there.