Registry system

The most important piece of this new ensemble is the Registry system which we'll use for Wesnoth-UMC-Dev. Being a project that manages several, not necessarily interrelated subprojects, I decided that we needed to come up with a custom hierarchy for administrating the repository. Originally, this hierarchy was pretty flat, and all developers had unrestricted access to all objects in the SVN directory tree; this later changed by the end of 2008 when Turuk joined to help us. He was not granted complete administrative control of the project via the SF.net membership management page, but instead he was turned into the first half-admin developer. The implications of this charge are suggested in our staff listing online, but the actual terms are described in detail in our internal documentation.

“Thoria” is the codename of this registry system which will be shared by our utility programs. It's fairly simple:

• The repository has projects.
• Projects have associated treeish objects in a standard filesystem-like structure.
• Individual projects are worked on by users (think developers).
• Certain users known as Half-admins and admins oversee the interactions between projects, users and trees.

The simple configuration system (libthoria) used by these utilities, reads parameters from a plain text file with a format that I derived from older hybrid-based ircds for no reason at all — okay, I actually wanted to play with writing config parsers by hand, since I can't be bothered to use any existing parser generator yet.

Example config with our current admins and half-admins who also happen to work in an individual add-on:

# userid, realname, forumname, ircname, email
U:shikadilord::shadowmaster:shadowmaster:username@eat.shit.spambots.tld
U:ai0867::AI:AI0867:username@eat.shit.spambots.tld
U:espreon::Espreon:Espreon:username@eat.shit.spambots.tld

# userid, svaname (IRC services account), hostmasks
A:shikadilord:shadowmaster:*!?=ignacio@wesnoth/developer/shadowmaster
A:ai0867:ai0867:*!?=ai@wesnoth/developer/ai0867
H:espreon:Espreon:*!*@wesnoth/developer/espreon

# project id, usernames, paths
P:Invasion_from_the_Unknown:shikadilord,ai0867,espreon:/trunk/Invasion_from_the_Unknown,/branches/1.6/Invasion_from_the_Unknown

Given the repository's current structure, some ambiguity may surround the nature of those branches that don't belong to any project in particular, under this scheme. To avoid introducing any kind of exception system to Thoria, those branches will simply belong to several hidden projects whose developer lists are empty — after all, admins and half-admins are given the right to interact with the whole repository by contract, so to speak.

# project ids prefixed with @ are hidden from user front-ends
P:@wesnoth-umc-dev/maintenance-toolchain::/branches/maintenance-toolchain
P:@wesnoth-umc-dev/shikadibot::/branches/irc-bots/shikadibot
P:@wesnoth-umc-dev/pykadibot::/branches/irc-bots/pykadibot

umcreg

The Registry service IRC bot, also codenamed “Thoria”, implements a convenient mechanism for interacting with the repository layout itself. Since Wesnoth-UMC-Dev relies on the IRC services provided by freenode, it seems logical to take advantage of their authentication system and Wesnoth-UMC-Dev's status as an informal subproject of Battle for Wesnoth (as far as freenode's group registrations are concerned); this way we can skip the development of a new authentication layer for our admins and half-admins.

umcreg will use freenode's services to determine who is speaking to it and what kind of privileges they have. Half-admins cannot do some things that admins can do, and regular users certainly don't have any business with the Registry system.

This bot is written in Perl using the Net::IRC module to facilitate progress so I can proceed to the next step in implementing the Registry; and at the same time, I learn more Perl that could be useful for future projects of any kind.

umcreg's web front-end

This is expected to be a Perl CGI script that will share some functionality with umcreg (specifically, the Thoria::Basic module) to read the Registry and generate a neat report of the repository structure for users on the website. In other words, this front-end will be the reincarnation of our ill-fated Wesnoth.org wiki page — except that is contents will be always up-to-date as long as we make proper use of its companion IRC bot.

umcstat

The Statistics service will be a somewhat different piece of machinery for managing Wesnoth-UMC-Dev by IRC.

umcstat is intended to provide regular users with useful informations about their projects, and to keep track of the treeish structures hosted and who interact with them, notifying admins and half-admins of anything unusually wrong, or unusually cool; for example, commits by authors to projects on which they aren't members, commits accidentally containing blacklisted object (file/dir) names, and administrative actions on object trees, to name a few.

I also intended to implement umcstat using C++, and I have the basics written and stored in my hard disk. Whether this will continue to be the case for the end product remains to be seen; while Perl and Net::IRC are undoubtedly versatile, they also have a few shortcomings of their own, including syntax quirks, high entropy, and, mostly in the case of the module, inflexible design for specific implementations. If I go ahead and complete umcstat as a C++ application, it will also be my first experience implementing a networked application using the IRC protocol, or any protocol at all.

Of course, there are many IRC-based applications out there with source code available under OSD-compatible licenses; however, it is my opinion that mixing third-party code together with my own can only result in an unmaintainable code ball from which I won't even learn, which is the last but not least important purpose of this exercise. Admittedly, it's taken longer than I wanted, but so's life.

Whether umcstat will also help in IRC channel management or umcreg will fulfill this duty — currently assigned to shikadibot — has yet to be decided.

Summing up

While Wesnoth-UMC-Dev saw very little activity the past year, with only one mainlined add-on (Delfadors' Memoirs), one newly introduced candidate for mainline (Dead Water), one new half-admin and one missing one (Espreon and Turuk, respectively), and only a couple of new add-ons being actively maintained, this could be a better year for the project — we could research into marketing strategies — and this means that admins and half-admins will perform better with some automated help for managing the repository.

umcstat is quickly becoming vaporware, similar to After the Storm's case, but there's always the hope that I may eventually gain access to the adequate combination of inspiration, concentration, time and energy to finish it — especially once umcreg is completed, which may be sooner than I thought.