don't worry, it's probably fine

Notes from the Week #28

03 Aug 2019

weeknotes gds mental health testing

Here’s a non-exhaustive summary of what happened this week.


The work I mentioned last week to run our smoke-tests from a different data-centre is effectively complete.

We’re running the new system in parallel with the existing system of checks for a bit to ensure that they behave the same before switching off the existing system.

I’m consistently impressed by the thought that’s clearly gone into Concourse CI’s domain concepts and API.


I’ve almost finished the write up for the “Mental Health in Software Development” session that I ran last month.

It turns out that writing up an hour and a half of post-its into a structured blogpost takes a while, but I’m pleased with how it’s coming together.

I’ve had a couple of realisations during the reflection on the session, especially around intersectionality with regards to mental health and other kinds of diversity, but more on that in the post.


Wednesday was a bit of a rough day - for whatever reason, I was off my game and wasn’t as well equipped as I would have liked to contribute during a 2hour mapping session.

I was annoyed at myself about this for a while, but going for a brief walk helped clear my head. In future I need to be better about just stepping out of the room if I need some air, much as I would be okay with it if someone else asked to.


I have to sign some of my commits at work to verify that they’ve come from me. It’s been a while since I’ve needed to do this, and it’s got me thinking about a problem I ran into while pairing/mobbing.

git supports signing commits and tags, but with a single key. How can you verify (a) that a single commit was paired/mobbed on and (b) the people whose names are on the commit were actually involved?

I’m playing with a rough idea of “primary committer signs the commit, secondary committers create and sign unique tags”, with something like a pre-receive-hook on the git server, which has a list of allowed public keys and rejects pushes where there are <2 verified authors.

The disadvantage of this is that tags are deliberately lightweight and easy to create, and so just as easy to delete. I suppose that this could be enforced on the server-side too (forbid deletions of tags).

The tag itself would have to have a unique id, something that uses the short-hash of the commit like a8b7c6-co-author-1. If tags were being used for release management, this might “pollute” your tag history to an unacceptable extent.

However, these might be acceptable trade-offs for being able to verify that everyone who claims to have worked on the commit did actually do so (assuming decent protections of each person’s signing key).