Bugdar 2 is now sufficiently far along that I’m comfortable posting the git repository. The Phalanx repository has been public from the beginning (albeit unnanounced) at Github: http://github.com/rsesek/phalanx. Bugdar 2′s repository is now also available there: http://github.com/rsesek/Bugdar2. At the same time, they will be availiable at their canonical home in http://bluestatic.org/git/. The Github mirrors are just easier for most people.
Development of Bugdar 2 is still moving fast. In the past few days I’ve laid down the core of the search system and added support for resubmitting a POST request after login (don’t lose your work if you’re not logged in). There’s two more major milestones before I consider us past the ‘first alpha’ stage: usergroup permissions and bug attributes. What are bug attributes?
In Bugdar 1, there were a set of fields that Bugdar compelled you to use: product, version, status, resolution, priority, severity, and assignment. If you didn’t want to use one of these fields, you couldn’t remove it — you just had to ignore it. There were also custom fields, but the architecture under them was always shaky. By having all these required fields, we were defining a bug as so:
CREATE TABLE bug ( bugid int unsigned NOT NULL AUTO_INCREMENT userid int unsigned NOT NULL dateline bigint unsigned NOT NULL product int unsigned NOT NULL component int unsigned NOT NULL version int unsigned NOT NULL summary varchar(255) NOT NULL priority int unsigned NOT NULL severity int unsigned NOT NULL status int unsigned NOT NULL resolution int unsigned NOT NULL assignedto int unsigned NOT NULL duplicateof int unsigned NOT NULL dependency text NOT NULL hidden smallint unsigned NOT NULL initialreport int unsigned NOT NULL -- [A lot of other cache information here] );
That’s a lot of data! If a bug isn’t going to use one of those fields, it’s still going to carry around all that weight. In Bugdar 2, this is how we define a bug:
CREATE TABLE bugs ( bug_id int NOT NULL PRIMARY KEY AUTO_INCREMENT, title varchar(250) NOT NULL DEFAULT '', reporting_user_id int NOT NULL DEFAULT 0, reporting_date int NOT NULL DEFAULT 0, hidden boolean NOT NULL DEFAULT 0, first_comment_id int NOT NULL DEFAULT 0 );
That’s a huge difference. You’ll notice all the attributes — the metadata — are not stored on the bug itself anymore. Instead, that’s done through a tuple:
CREATE TABLE bug_attributes ( bug_id int NOT NULL DEFAULT 0, attribute_title varchar(50) NOT NULL DEFAULT '', value varchar(250), PRIMARY KEY (bug_id, attribute_title) );
The implications of this are that an single (unique), arbitrary attribute can be attached to a bug at the user’s will. The requirement of data is now imposed by the administrator rather than the developer. It also helps to normalize the database schema. So how do attributes work?
Attributes can be defined formally in an administrative panel, or they can be defined ad-hoc while editing bugs. Attributes can be titled to create a field, or they can just be values, which will be represented as tags. The goal with this system is to create a highly flexible data model in which all the stock Bugdar 1 fields could be represented as attributes.
Formally defined attributes can be one of five types: text, boolean, list, date, or user. Text fields are self explanatory. Booleans are interesting because they don’t necessarily have binary value; they have ternary value: true, false, and unset — but that’s more of a semantic detail. Lists are a set of selectable, pre-defined options. The last two types are new since Bugdar 1. Date fields will have a calendar selection widget. Finally, user fields allow the bug to be attached to some user in Bugdar’s system; this is how assignments work.
This is a rendering of how attributes will be arranged on the bug display:
That same information takes up more than half the page in Bugdar 1. That’s all for now.