Nibbs Carter of Saxon.
Just over a week ago, I finished my month's work experience at Red Hat UK
, and I'm pleased to say it went well. I learnt lots about how Red Hat works, dived into the kernel for the first time (and worked on some kernel patches!), got an RHCT
qualification, and generally had a good time with our resident frockney
. Hopefully he's managed to clean his house up sufficiently after my departure.
The reason for leaving Red Hat mid-week is so that I could go to Bloodstock
! It was a brilliant weekend, with the highlights being Die Apokalyptischen Reiter, Saxon, Satyricon, Turisas and Amon Amarth. Photos are up on PicasaWeb
While sorting out the photos of Bloodstock, I also went through all the photos I took while in Gran Canaria for GCDS, so they're also now up on PicasaWeb.
I've been fortunate enough to have been reviewing a lot of patches recently. Fortunate, because it means other people are contributing to my library. However, few of these contributions are without their problems; as with all contributions, each patch generally goes through two or three iterations before I think it's near enough to being ready that it's easier for me to apply the patch than it is to comment on it and request an updated version.
Generally, when patches get to this stage, it's just the really small, nitpicky things which are still wrong. Rogue whitespace, quirky indentation, typos in documentation…these are all really minor things, but they take time to check through and correct. One of the latest libgdata patches was, I think, a bit of a rushed job; and so there were more of these niggly problems than usual. Instead of going through and fixing all the problems and never giving detailed feedback about them to the patch contributor – as is usually the way, since the changes are so trivial, albeit cumulatively not inconsiderate – I decided to make a screencast of the process I go through when reviewing a patch.
Reviewing and applying a patch
It's about half an hour long, unscripted and unedited, so there are a couple of mistakes and omissions in there (for example, I later noticed I'd forgotten to mention the lack of input validation on the new function). However, I think it's quite comprehensive. It's aimed at those who are getting used to the open-source patch submission and development process, though those more talented than me welcome to watch it and lambast me for not using Emacs. Hopefully it's useful to someone, anyway. It's licenced under cc-by-sa 2.0.