Archive for August, 2010
As of this week, the re-motion project has a publicly available issue tracker, courtesy of Atlassian’s JIRA and Patrick Größ, who took it upon himself to tame the beast. Aside from setting it up and integrating it with our DMZ, this also meant integrating it with our internal processes here at rubicon. I’ll get to this at the end of the post. But first, I’d like to spend a couple of lines on our versioning policy and outlining our development process.
re-motion’s version numbers are designed to follow the classic trunk/stable version scheme used by various open source projects, not the least, the Linux kernel. This means we use the minor number to indicate the level of support a version receives.
- Uneven minor version numbers (1.11, 1.13, 1.15, etc) indicate that the version was built from the trunk. This is the main line of development in re-motion, and we don’t make any guarantees beyond our test-coverage for those versions. This means the APIs are more likely to break repeatedly on the trunk than they are once an API is considered stable. Also, we do not offer hotfixes for the trunk, no matter what. If there is a problem, it will get fixed but you do have to upgrade to the next version that contains the fix.
- Even minor version numbers (1.12, 1.14, 2.0) indicate that the version has been declared stable and resides in a distinct branch. Here, it is possible to receive a hotfix if there is a serious bug in the code. On the downside, you won’t get new features until we release another stable version and you upgrade again.
So, now that that’s out of the way, let’s talk about the third part of the version number, often referred to as the build number.
For the trunk, this number represents the individual XP iterations of re-motion’s trunk and gets incremented every week. You can also check out what’s planned for the week via the “re-motion current iteration” filter result displayed on the JIRA’s dashboard. Right now, we’re working on version 1.13.70, the ‘70’ indicating this is the 70th iteration on the 1.13 trunk.
For stable versions, the build number indicates a hotfix release. So 1.12.3 is the third hotfix for the 1.12 branch.
The following issue types are available to all users:
- New Feature: Represents a feature request by a user. Basically, any sort of feedback that represents the wish for added, improved, or changed functionality of re-motion. They’re also the highlight of our release notes. After all, who wants to read about tons of bug-fixes in a release? I prefer my features to be bug-free the first time around.
- Sub-Feature: In case you envision a really big feature, you can break it down into sub-features. Typically, though, that’s only done by re-motion’s developers after spending a lot of time in front of a whiteboard.
- Performance: In case you find an issue with re-motion that hampers your application’s performance, you can explicitly declare it as such.
- Bug: Represents feedback on a piece of re-motion that does not work as documented (or obviously intended). Please keep in mind that we reserve the right to change a bug report to a feature request if it’s not a bug but a feature 😉
The other issue types are only intended to be used by re-motion’s developers as they represent artifacts of the previous issue types.
- Task and Sub-Task: Those are to-dos for re-motion’s developers, directly derived from a reported feature request or sometimes a bug report. They’re the only issue types excluded from our release notes and contain the technical information only relevant to the poor soul having to implement it. They also show up in the Subversion log messages and link a change-set to a task and subsequently to a feature.
- Breaking Change: This is the big one. The one nobody likes. But since we don’t guarantee everlasting APIs like Microsoft does, introducing the odd breaking change is acceptable if it keeps the design clean, makes the API better, or is plain and simple necessary to implement a feature request.
We’ve looked at what other projects do. We’ve looked at the defaults provided by JIRA. And after much debate, we decided to offer only two priority levels when dealing with issues:
Normal, I guess, should be pretty much self-explanatory. So, what about critical? Well, that’s easy. In case you stumble across a bug that stops your project cold and for which there aren’t any (sensible) workarounds, please assign it a critical level of priority. We do strive not to have any of those, at least in the unresolved category.
The resolution type is the distilled reason why an issue has been closed.
- Fixed: This one’s easy. The task was fully implemented.
- Won’t Fix: Sometimes, an issue reported cannot be resolved by us because it would break some other invariant of re-motion. In such a case we like to make our point clear and close the issue as won’t fix. Usually, though, we try to explain our reasoning first and only close it as ‘Won’t Fix’ after a consensus has been reached with the reporter about why we won’t fix the issue.
- Duplicate: There’s already an issue in the system referring to the same bug or missing feature. In this case, the two issues get linked and one of the issues gets closed as being the duplicate. Which issue this is depends on lots of things, such as the amount of detail in the respective issue, whether the other issue is already scheduled, and, maybe, on the tea leafs left on the bottom of the cup on the developer’s desk.
- Obsolete: In case fixing one issue invalidates another issue completely, this issue will get closed as obsolete.
- Cannot Reproduce: Last but not least, in case we can’t make heads or tails of a bug-report and the reporter hasn’t updated the issue with more information, we will close it as ‘Cannot reproduce’. Another reason would be if the reported behavior is the result of an application error instead of a bug in re-motion.
The issue status describes the present state of affairs for any open issue.
- Open: Nobody is working in this issue right now.
- More information needed: We need more information about the task, usually from the reporter. This request always includes a comment and the task being assigned back to the reporter. Please make sure to check on your issues either via e-mail notification or by visiting our JIRA regularly because if we don’t have the information needed to reproduce or solve a problem and the reporter doesn’t seem to care, the issue will get closed as ‘Cannot Reproduce’.
- Closed: The issue is done and the resolution type is set to anything but ‘Unresolved’.
- In Progress: A status only relevant to developers. It indicates that the assignee is currently doing work on this issue.
- Review needed: Another one of those internal statuses. The assignee is done with the task and would like the reporter to check the work.
- MarkAsDeleted: This one’s needed in case an issue has to be deleted from the system. While we strive not to do that with user-reported issues, we don’t have the same scruples when it comes to obsolete developer tasks.
- MarkAsClosed: This one’s basically the same as the ‘Closed’ status and it only exists because our infrastructure behind the scenes needs it. Normally, no issue has this status for more than a minute or so, and if we had the option of hiding it from the UI, we would.
Registration and Account Management
Our JIRA is integrated into the rest of re-motion project’s community platform. This means, primarily, that you can use the same user account when reporting issues, participating in our forum, or our Wiki.
Unfortunately, those two are still work in progress, but the context is relevant since you can’t register directly with JIRA but instead have to visit our portal site. Afterwards, you can use the same user credentials across the entire re-motion web-site. [Update 2012: You can register on the login-page of jira and use the same credentials for wiki and the forum]
What’s going on behind the scenes? From time to time, you will notice that the JIRA Sync user has updated a task, sometimes even re-opening and then closing it. This activity originates in our backend service and is used to sync re-motion’s JIRA with our internal issue tracker here at rubicon. We tried to make it as unobtrusive as possible, but unfortunately, we can’t hide its activity completely. So, if you have activated e-mail notifications, you can safely ignore those sent by the “JIRA Sync” user. [Update 2012: The sync-process has been retired. Instead, we’re now using Atlassian’s application-link feature.]
So, I guess that’s it for today,