The Goldfish Chronicles

I just got a letter letting me know that the Linux Fund credit card I had with MBNA was being discontinued (I’m guessing as a direct result of Bank of America being the new owners of MBNA). As of June 30 2007 it stops sending money to LinuxFund and then on to open source projects.

So a couple of thoughts. Firstly - gah. I liked that I was sending money to projects, and the penguin makes an impression every time I buy something (cute, alternative or cool). Secondly - anyone able to recommend a new card?

Given the theme of my blog, I couldn’t resist mentioning this boingboing entry about Goldfish living in a deep fat fryer.

Unless I get seized by some creative muse, this is probably the last JIRA bit for a little while as I’ve nothing left unreleased and only a couple of minor wishlist items in my head currently. Time to think of a new plugin I think.

Anyway, I’ve released 1.0.2 of the FilterList plugin. As I said in a previous post, this is the oldest of my plugins at a stunning 5 weeks or so of age. It’s had 6 releases during that time, 3 of them public. 1.0.2 is a second minor bugfix release with a bug found by a user (clicking on Go when nothing is selected), a switch from a HTML submit button to an image and an i18n improvement that I noticed. Enjoy.

For more info, here’s the website.

My main JIRA plugin work for the last few days has been a beefed up version of the release status portlet. Apart from the version health, all of the highlighted features below are new:

The new features can be split into two parts.

Firstly, there’s a new top bar to the portlet. It shows the Project the version comes form (important when a version might just be ‘1.2.2′), and provides handy links on the right hand side. Most notable of these is the ability to toggle the portlet between the current user and all users. This toggle can be set to either by default.

Secondly, you can now chain a series of versions together. This is mostly a real estate saving concept, as it’s common to be planning multiple versions at the same time if not always working on them. It’s also useful to tie a series of milestones into a version-group. JIRA lacks the concept of milestones, so this lets you setup your milestones and then give your users a way to visualize the version as a whole.

The only thing I have planned for this plugin is to find a way to replace the poor JIRA Release Notes page, but that’ll take some time so now’s the time to give these portlets a try.

I’ve released a Search plugin for JIRA. It was born of some confusion over just what the Quick Search feature was doing, but it still has value I think. It’s a simple thing to look at:

The exact problem we were hitting was that the Quick Search doesn’t like you searching for things that look like an issue key. When your JIRA is used to track other issue trackers, you find you want to search for ‘DBCP-23′ quite a lot and it’s frustrating to have to go onto the rather clunky Find Issues page. Using the Quick Search though will give you an ‘Issue does not exist’ page.

There are some other reasons. I’ve never liked the new users view of searching in JIRA. There’s a Quick Search textfield in the top-right, and a somewhat cryptic ‘Find Issues’ link on the top bar, but both are drowned out by the immediate content in front of the user and I think people don’t easily see either. There’s great value in having people able to do a text search on the front page (find previous bug report before reporting it), so I think this little plugin has great value in such places.

I’d like to enhance it so that people can customize it to look at custom fields, but that’s going to be a bit of work I suspect. JIRA tends to think AND instead of OR.

The last few blog entries have been mentioning the JIRA plugins I’ve released. Carrie and Nathan have definitely suffered over the last week, I missed the bus twice last week because that last hour of play at work had turned into two, and both have had to deal with my habit of talking out loud when I’m thinking about things. That was all for the Release plugin. So thanks especially to Carrie for putting up with that.

The other plugin (FilterList) has an older history. It’s something I’ve wanted for a while, but had never found the energy to work on. Grief is an odd thing though, and I’ve noticed that my preference is to find flow and let the grief work its way through my subconscious. The subconscious let the sadness through from time to time, but it also resolved many of the thoughts with a strong urge to live life. Sadly for my family, that means finding flow in code and doing/learning new things. Thus I dove into JIRA.

FilterList was written the Sunday after we found out. I knew I had to make sure I was available as much as possible for Carrie and Nathan, but I also knew I needed to find time to lose myself. It took an afternoon/evening. It’s very little code, but there’s so much Javadoc for JIRA that it takes an age to find the one that does what you want. On the plus side, it’s pretty easy to end up with something that looks polished and professional with JIRA, so the payback for the work is incredibly high.

I suspect I’m the first person to find solace in an issue tracker.

I love Open Source. I spent some part of today emailing back and forth with a user of Filter List who had found a bug (I’ve got a user already, that rocks so much).

Turned out I’d hardcoded a /jira/ in the create-new/manage links so that’s now fixed and a 1.0.1 released.

The comment from Niall on wanting the Release Status portlet for Commons made me ponder. The Filter List plugin was designed specifically to save some real estate and to make it easy to find the four triage filters that my colleagues and I use every morning. It’s a bit spammy to force those four links on everyone else in the company, but it’s a small company so not that big a deal (plus I’m the JIRA admin so I can go lalala if people complain too softly).

The Release Status plugin was designed specifically to highlight a particular release. That’s going to work really well for Don and his desire to use it in Struts; though the lack of either Due Dates or a Release Date mean that some of the fields will either not be appearing or will always be zero, but as Commons lives in the much larger main ASF repository it’s not something that can go on the main dashboard. Not unless I add a ‘random “release of the week”‘ bit to add a bit of fairness.

So that got me to thinking - what would be good for the ASF? And the answer that popped out was a way to see the latest releases from the ASF. So in a rather worryingly successful hour of coding I put together the Latest Releases portlet and bundled it in with the Release plugin.

Here’s a quick screenshot:

As I was up to speed, I poked at another plugin I’d been working on a week or two back. Part of the dayjob involves digging into the history of projects, and it’s highly irritating how many projects don’t provide a page saying when they released v1.0, v1.1 etc. The ones that spring to mind are mostly all in Jakarta Commons, so something I’ve been able to do as I dig through this information is to update the release information in JIRA for each component. That’s why I’m doing the job, with one piece of work I can achieve both a company thing and an open source thing.

There’s a hitch though. That information is only available to people who can administer the project. So I added a Releases project panel that details the history (think ChangeLog, but without all the issues spammingthings) and with myself truly in the flow I quickly got it looking how I felt it should look and it was ready for release as a part of the Release plugin.

Again, here’s a looksee:

Both have now been released in version 2.0 of the Release Status plugin.

Convince your JIRA admin to install them

I’ve been having fun in the spare moments at work by working on a bunch of JIRA plugins, and I just released two of them for others to use. They are little things, but they’ve been useful.

The first is an improvement on the Saved Filters dashboard portlet. Rather than a big list of all the filters, a JIRA admin can choose to put them in a HTML <select>

and/or to specify the filters that are shown either by explicitly listing them or via regular expressions.

I call it: Filter List Plugin.

The second is a portlet for showing the status of a version on the dashboard (rather than the project page). It does the expected things - showing the activity in the last 7 days and providing information on how many issues are resolved/outstanding; more importantly it also gives you an icon to show you how the release is looking:

I call it: Release Status Plugin.

Small things I’m sure you’ll agree, but they were fun to code.

I’m starting to turn into a nomadic open source release catalyst. At least for the last few months. This is because my colleagues and I are deciding on stable versions that will form the core support versions for the next 9 months and it’s nicer to make a release happen at the source than do lots of backports.

Now that lots of Commons releases are done (DBCP 1.2.2 and Logging 1.1.1 still need to happen), the next on my list is Quartz 1.6.1 and I get to try out my belief that a non-committer can enact change. Here’s how I tell people to do this in Commons when they ask on commons-dev@:

1. If you’re not sure if another release is warranted, ask on the mailing list - ie: some components are done
2. Create patches in the JIRA
3. Put together a release plan on the wiki
4. Bring the subject up on the mailing list
5. Loop over: Wait for activity, get involved, remind the list of the plan
6. Release! (?)

Currently it bodes well for Quartz 1.6.1. I’ve followed the above list and put together a release plan on their wiki and have applied patches to many of the issues over the last month or so. More importantly, the committers have a theme for the release (minor bugfix release) which helps to focus the activity.