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).
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:
What you don't get (yet):
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.
Enjoy!
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.
It's time for another mtrack update; here's what's new:
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.
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.
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.
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:
[plugins]
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 "http://netevil.org/" 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]
http://netevil.org/ = 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:
[plugins]
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.
Enjoy!
mtrack home page: http://bitbucket.org/wez/mtrack/wiki/Home
mtrack mailing list: http://groups.google.com/group/mtrack
[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?
Why didn't you use <Name of Framework>?
How do I install mtrack?
How can I contribute to mtrack?
You started this article claiming that all other issue trackers suck, but I think mtrack needs improvement
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.
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!