The Goldfish Chronicles

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.

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.

After a bunch of ‘we should do a podcast’, David finally managed to corner me for long enough to do an interview.

There are a few acts of arrogance on my part that make me wince. I wasn’t the only one to work on splitting up Commons Util - from memory Daniel Rall did a lot there; talking about being surprised at getting a good number of votes is a bit arrogant (though many thanks to all who voted for me); and I seemed a bit back to front when answering whether I thought I would get voted onto the board. Prior to the election I wasn’t expecting it, but after the election (with hindsight), I realised that with 9 spaces and 14 or 15 candidates you’ve got a better than average chance.

There were things I wanted to say that I didn’t manage to bring up. One big problem I find on the board is a sense of silence. My view of a chair, and a board, is much like the speaker in the house of commons. They are a member of the parliament, but they tend to hold their opinion back until they need to be giving it (ie: in a draw). So I hold back on pmc mailing lists because I want to let the pmc do their thing [and yet I’m part of that pmc].

David did a good job of editing - I tend to pause for a bit when asked a question while I think and he cut that out. Probably halves the length of the interview ;). I also um and err a bit and he managed to reduce that. Something I’ve noticed from the previous podcast that I had a couple of sentences on is that I’ve picked up a habit of having my inflection go up at the end of the sentence. I didn’t really notice it until I started doing board calls (takes the others a moment to realise I’ve finished) and it’s something I want to get better on. Apparently it’s an American habit. I don’t do as badly on the interview with David (I think).

I do speak fast. Screw you all

Today I built my first rpm. Pretty minor as it turns out - CruiseControl ships with a spec file and an Ant build.xml to do the work, so it was mostly about learning a bit about Yum and rpmbuild and .rpmmacros. Worked pretty well and then I sat and newbie’d with the installed CruiseControl, following the documentation to setup a build for Commons Lang.

CruiseControl (unsurprisingly) reminds me of Ant. You have to do a lot of work to get things setup, but you also have a lot of control. Continuum is the Maven (wow..shock!) in that it does more for you, but it’s harder to have control. Of course this is from a short period of use, but I like that CruiseControl is configuration file based, somehow that feels better than Continuum’s database approach. It is noisy though, so I have an urge to make a CruiseControl config file generator.

Thanks to Niall nudging me on the previous post, I took a look at the other validwhen issues. A couple are basically the same thing, decimals aren’t supported, so I commented on that and had a quick play to see if I could add it. No luck - but I do like doing lexer bits (it’s very like regexp) now that I have an actual example to use it on. I wonder what I did with my Lexx & Yacc book.

I added Cayenne and ActiveMQ to the front page of the Apache site. If you didn’t know - both projects have left the Incubator and become full on Apache projects in this ever growing enterprise borg that we’ve become. Also a link to ApacheCon as a Related Site and a search bar that uses Google rather than the 4-year old and utterly not maintained search.apache.org (swish-e perl module).

This evening I tried showing Nathan a Spiderman & His Amazing Friends cartoon after he liked The Incredibles the other day. It was pretty lame, but he seemed to find it watchable. Definitely not amazing though.

Time to make cookies… (cocoa oat cookies).

A much lighter day today - mostly because the morning was filled with going to the dentist to have my teeth worshipped (yes, I’m British and the US dentist does not run screaming… huzzah!). Apart from the usual work stuff of checking out the day’s new bugs (and reading work email and the various ASF lists), I spent a couple of hours figuring out Antlr generated code for the Struts validwhen validator (cf: STR-2997). I’m pretty chuffed that I got a fix+test patch in and that I improved my understanding of Antlr in the process.

Looks like Lang 2.3 may be held up a bit. There are some minor issues that’ll probably get improved a touch, but most importantly it looks like refactoring to one of the classes (Entities) undid the optimisation that a previous issue had asked for. So time for a bit of thinking to figure out how to change the refactoring so as not to hurt the speed.

I started listening to the Open Rights Group mailing list the other day. A Slashdot link (yeah I still read that occasionally) referred to them as the UK’s version of the EFF. Interesting stuff to keep track of.

Kicking myself to blog about what’s happening and not feel a need to say anything profound (which is good as I rarely do).

Today saw the announcement for the Commons IO 1.3 release. This was a cool release for me - I had an osjava project named gj-find which was basically an attempt to create a library that would be as useful as I find the find command is on a unix command line. I think I succeeded (by my level of need) as it was a library I grabbed from time to time to do said functionality. I brought it to the Commons Sandbox where Niall Pemberton gutted it and along with Stephen Colebourne took the valuable parts of it into IO where it led to a bunch of new filters and a new DirectoryWalker class. I’ve no idea how much of my original code survived, but that’s less important than surviving peer review and having value. The find code still exists in the sandbox and has been changed to use IO 1.3, however there’s not much left and I suspect I’ll propose it for dormancy.

I also built the first release candidate for Commons Lang 2.3. I like Lang. It’s a very good tool to have in the toolbox, especially if you’re writing applications. Less so if you’re writing libraries as you often end up fighting the desire to import a Lang class to do something boring and simple as you don’t want the dependency. Once 2.3 is out I’m very hopeful that people will be interested in a Java 1.5+ dependent version of Lang that can branch out and look at lots of new things. I’d like to see if there are helper functions that could exist for Regexps and for Java logging to start with. Speaking of - it’d be interesting to see if there’s useful stuff that Commons IO could add for NIO coding.

I moved Jakarta Standard Taglib 1.1.3 a bit closer to happening. I’ve been keeping a history of what’s been going on on the taglib wiki. It’s been a while since I’ve done Taglib work, but it’s kind of fun to dip into it again. Once this is done I really need to gut the Taglibs project and retire the majority of dead taglibs. Maybe push the Unstandard Taglib again by pulling the bits of each taglib that have value into it. I’ve emailed a status update to the taglibs-dev list today, hoping that some people offer a reply or two.

Of course some company work went on - and I also spent some time with JIRA today - doing a test update to 3.7.2 and playing with plugins. I’ve become the company JIRA admin simply because I enjoy working with it. I had some personal custom dashboards for a long time (why oh why can we not share these?!?) and finally dumped them to work on a default dashboard for everyone. I’m using the JIRA Calendar Plugin to show people’s todo list and people seem to like that a lot. I’m playing with the Labels plugin (tagging) and the Chart plugin (pretty graphs). Soon I hope to start writing some plugins of my own.

No day would be complete without a walk through random mailing lists and JIRA projects. A few issues nudged along or closed on the INFRA JIRA project, an svn migration, an email to Roller suggesting they talk about graduating from the Incubator, and a couple of board emails.

All in all, not a terrible day. Feels good to sit down and put it on paper so to speak - my random wandering from project to project often means I end the day thinking not much has really happened.