Skip to content


mtrack repo ACLs

Updated: Added schema and UI for Projects to own repos and manage groups.

Following through on user repos and SSH, I revised the ACL support in mtrack and added a permissions editor for the repo editing screen. When you create a repo, it defaults to granting you (the creator) full access and denying everybody else access (equivalent to a private repo in services like Github and Bitbucket).

mtrack user repos and ssh

I've just pushed a somewhat experimental change to the default branch of mtrack that enables per-user repositories, repository forking, SSH key management, and SSH repository serving integration.

It's important to stress that this is preliminary in as much as restrictive controls are missing. There are some ACLs and rights around repo creation that are not yet implemented. Additionally, if you are using OpenID, any authenticated user will be able to add an ssh key and access the mtrack created repos (but nothing outside of that).

What you get in the current tip:

  • Users can create Mercurial, Git or Subversion repositories
  • Delete your own repositories
  • Fork Mercurial or Git repositories
  • Associate your SSH keys with your mtrack login
  • Integration with SSH and Mercurial/Git/Subversion repo server

What you don't get (yet):

  • ACLs to control forking or access within repos
  • Pull requests, patch queue management
  • Graphs of forks and non-merged changes from forks

If you'd like to try these features, I'd love to hear your feedback. To update your instance:

$ hg pull
$ php bin/schema-tool.php

Then navigate to help.php/SSH (source text) to read about setting up SSH.


mtrack: burndown and postgres

It's that time of the month... mtrack update time. Not a huge number of items to report on this time around, but it's a decently significant stepping stone--the schema management code takes us one step closer to an upgrade/deployment process.

  • If you don't explicitly include the burndown macro text in a milestone, a default burndown graph will now be displayed when the milestone summary is rendered in the roadmap section.
  • Added schema management code to handle upgrades that change the schema
  • Added preliminary postgres DB support on top of the schema management code.
  • Revised attachment processing so that the database stores a canonical copy of each attachment. This step helps to enable multiple front-end web servers to be used with the same backend pgsql DB.
  • Created a stable branch that holds the changes up to just before the PostgreSQL DB changes

mtrack: custom fields, snippets

It's time for another mtrack update; here's what's new:

  • Add "Snippets" feature; works like pastebin, but allows for comments to be supplied in wiki syntax in addition to the code or text snippet that you're pasting
  • Add Custom Field support. This is implemented by modifying the schema (custom fields always have an "x_" prefix).
  • Improvements to the "custom ticket query" screens, including ability to select which columns (including custom fields) are included in the results
  • Fix an issue with sorting the "Remaining" time column
  • Fix some IE compatibility issues
  • Improve presentation of tickets in read-only mode
  • Refactor search engine code and allow the use of Apache Solr as an engine. Indexer logs are now viewable in the Admin section
  • Improve perceived search engine performance by forcing it to work in smaller batches
  • You may now delete attachments from both wiki pages and tickets
  • Add post commit hook for the wiki repo, so that changes made outside of the mtrack UI are noticed and indexed
  • Improve diff visualization
  • Add syntax highlighting facility
  • File view now allows blame and line numbers to be turned on or off, and renders with syntax highlighting
  • Allow optional "hour", "hours" and "hrs" unit after the spent time command in the commit hook (Thanks Andrei!)
  • Display remaining time as 0 if the ticket is closed

mtrack: facelift + other progress

I've been working on some changes to mtrack (a software development tracker implemented in PHP) this weekend, with a focus on improving the user experience for the mtrack administrator. To be brutally honest, it was at best a meagre experience for the administrator, but now things are better. They're still not perfect, but it should be a low enough bar to encourage more folks to play with mtrack. I've also spent a little bit of effort to add some caching to improve performance for certain pages.

For those that have tried it in the past, there's a brief summary of what's changed and a couple of screen shots below. This effort is in alignment with the roadmap that I published a little while ago.

mtrack: roadmap RFC

I wanted to share some of my thoughts on future development in mtrack, and solicit some feedback. Some of these are driven directly from user requests, and others are things that I've been thinking about on-and-off for a little while.

I really want to hear your thoughts, whether they relate to ideas and feature suggestions, or whether you have some experience or anecdotes on these topics.

Custom Fields

I was hoping to avoid having to enable this as a feature, as I find the implementation approach taken in the original Trac to be sub-optimal, both in terms of run time efficiency and in terms of user experience when it comes to reporting on the custom fields.

mtrack: now with OpenID and reCaptcha support

Some of the feedback and questions that I've gotten about mtrack were around making it easier to deploy and use in an open or public facing environment.

To that end, I've added support of OpenID authentication and bot detection via reCaptcha.

To enable these features is quite simple; for OpenID, add the following lines to your config.ini file:

MTrackAuth_OpenID =

You should also remove any other Auth plugins that you may have there, as how they interact with OpenID is not currently defined.

This will cause mtrack to keep users classes as anonymous until they either request to log-in via a link in the navigation bar, or attempt to access a page that requires privileges that the anonymous user lacks.

Users authenticating via OpenID can contribute to tickets and wiki (unless you change their permissions, either directly, or via their user class), and those changes will be attributed to them using their OpenID identity URL.

mtrack has a system for aliasing users from different repos and authentication schemes, so if you had a code contributor named "wez" in one of your repos, an administrator can add their OpenID URL as an alias via the user administration screens.  The admin user would edit the "wez" user and add "" to the list of aliases.  This will cause mtrack to see that OpenID as being equivalent to the "wez" user.

You can, if you wish, make an OpenID URL recognized as an admin user by adding the following lines to your config.ini:

[user_classes] = admin

This will have the effect of giving me admin rights to your mtrack install.

What about captchas?

Captcha's allow you to require that the person submitting a request be a human and not an automated submission agent.  In practical terms, this helps to avoid spam by limiting it to human spammers instead of spam bots.

To enable Captchas in mtrack using the reCaptcha service, go and register your domain and get yourself a private and public key pair.  Then add the following lines to your config.ini:

MTrackCaptcha_Recaptcha = pubkey, privkey

Where pubkey and privkey are your public and private keys respectively (you must not use double quotes).

This will cause a captcha to be displayed and checked in the wiki and ticket editing screens for anonymous and authenticated users; admin users will not see the captcha.


mtrack home page:

mtrack mailing list:

IRC: irc://

mtrack: a software development tracker + wiki

[Updated to add IRC and Google Groups links]

I don't know if it's just me, or whether everyone in software development finds issue tracking software frustrating and/or broken in some way.  They're all either way too complicated to set up, configure or use (the Bugzilla's or the Jira's), or have annoying "features" (such as Trac's you-lose-your-edits-if-someone-else-changed-something).

We've been using Trac at Message Systems for several years now and have been enjoying its pragmatic approach of keeping the interface simple but expressive; just enough structure to be helpful but not too much that it intrudes.  We've added/modified a couple of plug-ins to it to help track time and draw some graphs, but it has otherwise served us well.

However, we've got a couple of projects that have started to converge and overlap and it's frustrating to visit the two different portals to interact and stay on top of things.  As we scale up our development teams even further (we continue to have bigger and bigger plans!) this will prove to be more widely frustrating.

Enter mtrack; on one hand it's a clone of many of Trac's features (possible due to their pragmatic BSD license), but on the other it has some refinements in terms of its workflow.  What's important to me is that it is built to work with multiple code repositories and allows breaking out information on a per project basis.  It also tries hard to avoid losing your wiki or ticket edits if someone else updates things while you're working.

I chose to implement mtrack in PHP rather than continuing to extend Trac in python.  My primary reason for this is that I've seen web apps written with Perl and Python, and while there are certainly guru developers out there that can build some awesome apps, those languages don't really lend themselves to web development and that limits the scope of potential contributors.  While I can probably persuade some of my colleagues to code python web bits, I'll find it much easier to persuade more of them to code PHP web bits.  I'm sure this property extends outside of our organization.

We've been running our engineering department on mtrack for a couple of weeks now (after a period of running it in parallel to Trac) with just under 20 or so people using it actively as part of their day-to-day activities, so I feel comfortable in making this blog post to solicit input from the broader community, both in terms of suggestions and bug reports as well as potential contributions.

While I am soliciting feedback, I'd like to emphasize that this is still relatively young and that there is no support and no warranty; if you are the cautious type, this is not the time to try mtrack.

And now for some Anticipated Questions to pre-empt FAQ:

Where can I get mtrack?

How is mtrack licensed?

What are some of the key features in mtrack?

  • Trac style wiki syntax (all of its core syntax is supported)
  • Subversion and Mercurial repository integration (API extensible to other VCS)
  • Email notifications batch related information together to reduce the amount of mail you need to read; if you make 5 changes relating to a ticket in a 5 minute period you get one email with all 5 changes in it, instead of 1 per change.  Code changes that reference a ticket generate a single email with the ticket changes and the diff, not a separate email for each.
  • Issue tracking with configurable components, priorities, severities, milestones.
  • Define "projects" and associate components and paths within repositories with them to control who gets notified of changes.
  • Flot based graphing of Scrum burn-down based on time estimates and recorded effort
  • Wiki edits have in-built conflict resolution and the Issue tracker tries hard to behave reasonably in the case where multiple people are working on the same item.
  • Uses the Gravatar service to add some personality throughout the application.
  • Includes an importer to migrate your Trac project(s) into mtrack.
  • Has a plugin/hook API to support both core and external enhancements.
  • Uses the Zend Framework Lucene implementation for full-text search capabilities. 

Why didn't you use <Name of Framework>?

  • Frameworks can increase development overhead and I wanted to get this done.  Also, if I had used a framework, I would have to defend my choice against the others ;-). I am not morally opposed to contributions that adopt a framework, but would want to carefully assess the impact on longer term maintenance before doing so.

How do I install mtrack?

How can I contribute to mtrack?

  • By trying it out; I'm looking forward to hearing suggestions, comments and bug reports.  Please file them in the issue tracker: and keep in mind that you may not get a response until the following weekend (or even longer!) due to my busy schedule
  • By fixing bugs; if you've found and resolved an issue and want to pass a patch back to me you can do so either by attaching the patch or details on how to get at the patch to the issue tracker.  I recommend doing this by keeping your own fork on bitbucket as it makes it much more convenient for both of us.
  • By building out and sharing new features; I'm very open to adding new features.  My preference is to enable those by making the core modular enough that new features don't have to be part of the main mtrack code to be used by it.  This will keep the the core light and make it easier to share modules.
  • By fleshing out docs.  I'm the first to admit that mtrack could do with more documentation.
  • Join in the discussion in the mtrack mailing list or in the #mtrack IRC channel on freenode.

You started this article claiming that all other issue trackers suck, but I think mtrack needs improvement

  • I'm sure it does; it is still early days and I welcome your feedback (see above!)

Jumpstarting PDO

Lukas is making another attempt at jumpstarting PDO development.  I welcome this effort, and will do what I can to help fill in details and make suggestions.  Unfortunately, I'm just way too busy with work to be able to commit to more than that.

I also wanted to share some of my thoughts on why PDO has been in a holding pattern for a while, so that more people are aware of it and can work to avoid repeating the same mistakes.

The first thing to note is that the guts of PDO were hard to develop.  The PHP script facing API sounds simple enough, but the underlying libraries for each different databases work in different ways, and it was and is a challenge to build PDO in such a way that it can work in the most efficient way.

The second thing, which is really a follow-on from the first, is that the database libraries are complex and nuanced.  Some are relatively simple (especially SQLite and MySQL) and others are complex in divergent ways (ODBC and Oracle).  Making a great PDO necessitates having experts in each of those APIs and databases around as contributors, both for the core implementation and for unit tests.

Thirdly, there are a lot of databases out there. That requires a lot of resources for the PDO developers to do a good job; not just different database products, but also different versions of those products, need to be tested against.  This is also very time consuming.

This boils down to a lot of effort.

Personally, I enjoy working hard.  Tricky problems are the most satisfying kind to solve!  However, working hard when there is no payoff is the least enjoyable kind of work.

For a successful PDO, there needs to be "payoff" for the contributors to keep them happy and working at it.  In a commercial context, where someone sponsors development, the payoff is typically in the form of a paycheck to help cover the bills.  In a FOSS context, the payoff may be satisfaction from working on hobby coding, may be vanity in wanting recognition and appreciation from peers or end-users or may be seen as effort to help build out a resume for future career opportunities.  There may be other motivating factors too.

I've talked in the past about FOSS being "Itch Driven Development".  So long as the contributors feel the need to scratch their respective itches, they'll keep on doing it.  They'll stop if the itch goes away, or if the scratching leads to bleeding.

Bleeding is stuff that detracts from or otherwise lessens the payoff.  In a commercial context this could manifest as something that wastes time (and time is money).  In a FOSS context, this may also be the result of vocal and/or abusive or otherwise negative sentiments from peers or others in the community.

Bleeding is bad for the whole group because it can take a long time for those that were bleeding to want to try their hands at scratching again.  Whatever form the renewed PDO development takes, it would do well to try to avoid bleeding.  One way to do this is to follow the advice of Bill and Ted and "Be Excellent To Each Other".

At the end of the day, PDO (and PHP) is largely a volunteer effort, which means that it is something that will be worked on in the spare time of the contributors.  Because it is hard work, the payoff needs to be enough for them to individually opt to work on it after a hard day at work instead of choosing alternatives, like family, beer or Xbox.

If you're willing and able to help improve PDO by contributing development effort and/or unit tests, please make yourselves known on the PDO mailing list. We need a critical mass to reduce the effort that any one person needs to make, and once we have momentum on our side, I think that PDO can be improved rather rapidly.

CouchShare now on BitBucket

A few of my friends and associates may have heard me talk about the media server I've been running in my basement; I used to automatically transfer content from my tivo to a hard-disk in my basement so that I had more space for recordings on the tivo.  Since most of the recordings that I want to keep are now available via Hulu, I haven't had much call to use it in the last 6 months.

So, what is CouchShare?  It's a UPnP server that can share content from folder to an XBox 360 on your network.

It's written in PHP (and requires a tiny PHP extension to enable multicast support) and is written using the eventing framework that is part of the Alexandria codebase.

I wrote the code back in 2007 and it has served me well for a couple of years; it felt like it was about time I got off my backside and shared it with the world.

It is by no-means a polished bit of code; I think it's probably the sloppiest code I've written in quite some time, and it may well need a couple of tweaks to make an easier application out of it.

So, have at it: I've put the code up on bitbucket and I welcome code and documentation contributions!