Tales from the Gryphon

I have been meaning to write this up for a long time now, since I vaguely made a promise to do so last Debconf. I have also been wondering about the inefficiencies in my work-flow, but I kept postponing my analysis since there were still large gaps in my packaging automation since I moved off Arch as my SCM of choice. However, recently I have taken a sabbatical from Debian, so I’ve had time to complete bits and pieces of my package building framework, enough so that I could no longer justify putting off the analysis. I tried writing it up, but the result confused even me; so I instead recorded every shell command during a recent series of packaging tasks, and converted that into a nice, detailed, activity diagram that you see over here. This is as efficient a work-flow as I have been able to come up with.

Along with a git commit hook script, that parses the commit log and adds pending tags to bugs closed in the commit, the figure above represents my complete work-flow – down to the details of every cd command I executed. I think there are too many steps still.

Feedback and commentary would be appreciated, as well as any suggestions to improve efficiency.

There has been some discussion on the Debian development mailing list about adding hooks into ucf, to allow people to do things like committing files into different SCM branches. So, I thought I would help people out by letting them tell me where hooks would be useful, and so decided to do an activity diagram for ucf. Gawd, what a mess. I mean, I wrote this thing, and it boggles even my mind. See the figure for how horrendous code can get when it grows organically.

So, I decided to re-factor/redesign ucf, see if I could create a less complex activity diagram. On analysis, it turns out that ucf has just five actions it may perform, and which action it takes depends on which of eight possible states the configuration file is in.