Reflections on Worklogs

I have been maintaining so-called "worklogs" on this website for some time. I started them because my work integrating Guix and QubesOS did not generate a useful commit history for circumstantial reasons. In short, I was using the fork as a staging area for preparing commits that would be later sent to upstream. This is how I typically work on my personal machine - I create a checkout, I create and amend a commit, then I submit it upstream. For small scopes - such as a simple bug fix - this works well. It lets me present a polished piece of work that is easily consumed by the upstream maintainers. However, the integration work is categorically different. The scope is large and includes adding multiple features. It will also never be "finished". With a bug fix, we deploy a fix and the work is more-or-less done. Hopefully it includes a regression test; if the bug crops back up we need to address it again, but it does not make sense to have a separate branch open for every bug that might potentially appear. But maintaining compatibility between 2 constantly evolving projects is an indefinite amount of work. I am aware of strategies like feature branches for managing complex scopes such as this. However, I am also a strong believer in dogfooding. Before I publish a commit, I install it on my machine and use it. This would be difficult to manage if the work was spread across several branches. The entirety of the integration work could be kept in a separate branch, but then I would still be faced with rebasing. Guix provides the ability to create channels, which is the package management equivalent to a feature branch. This is what I will use moving forward.

I had also added worklogs for my other projects because I prefer consistency. At this point, this only includes one other project: this website. The worklog concept is less useful when the git repository has a complete history. I tried to make it more useful by including only work on the website itself, not commits that only change contents. The utility of this is questionable. Git has built-in mechanisms to examine the history of specific portions of the repository and there is a whole ecosystem of tools built around git.

There's not much more to say. I started the worklogs as a band-aid over an incompatibility between the workflow that I was used to and a new kind of work that I was engaged in. But band-aids only work for so long. It's time to fix the root of the problem.