maintenance

For the past few years, the number of issues and PRs across all my GitHub repositories has gone from a steady stream to an ongoing deluge. There are currently over 1,500 open issues across my 194 GitHub repositories, and there's no way I can keep up with all of them.

Initially, I went through each issue in each project's issue queue on a monthly basis (mind you, this was—and is still—done on nights and weekends in my spare time). That slipped to a quarterly task... and has now slipped to only happening for higher-profile projects once or twice a year.

As you get deeper into your journey using Ansible, you might start filing issues on GitHub, chatting in #ansible on Freenode IRC, or otherwise interacting more with the Ansible community. Because the Ansible community has grown tremendously over the years—and as Ansible has been subsumed by Red Hat, which has various support plans for Ansible—there's been a greater distinction between parts of Ansible that are 'core' (e.g. maintained by the Ansible Engineering Team) and those that are not.

When everything works, and when you're living in a world where security and compliance requirements are fairly free, you would never even care about the support for Ansible components (modules, plugins, filters, Galaxy content). But if something goes wrong, or if there are security or compliance concerns, it is important to be able to figure out what's core, what's 'certified' by Red Hat, and what's not.

I maintain a lot of Ansible Galaxy roles. I probably have a problem, but I won't admit it, so I'll probably keep adding more roles :)

One thing I see quite often is someone submitting a simple Pull Request for one of my roles on GitHub, then checking in here and there asking if I have had a chance to merge it yet. I'm guessing people who end up doing this might not know about one of the best features of Ansible Galaxy (and more generally, open source!): you can fork the role and maintain your changes in the fork, and it's pretty easy to do.

I just had to do it for one project I'm working on. I am using the rvm_io.ruby role to install specific versions of Ruby on some servers. But there seems to have been a breaking change to the upstream packages RVM uses, summarized in this GitHub issue. I found a pretty simple fix (removing one array item from a variable), and submitted this PR.

I found out recently that my new home's irrigation system was installed in the mid-eighties, and it seems most parts (the pex pipes for laterals, the 1" PVC for the run to the valves for four zones, and the backflow preventer itself) were well-built for that time.

Not much has changed—the fittings and main parts of the system are similar to what you can buy today—and the importance of winterizing the system (getting the water out of all the exterior parts) in colder climates has not been diminished!

I have a small 8 gallon 125-psi Central Pneumatic (inexpensive Harbor Freight brand) air compressor; it's not quite pancake-small, but it's no CFM (cubic feet per minute) champion, either. Rather than paying an irrigation company a bit of money to come out and use their monster compressor to blow out my system, I've MacGuyvered the process to get everything cleared out for the past few years. I want to document what I did here for two reasons: one, so I can remember all the steps in the future and avoid a half hour walking between my basement and the outdoor valves, and two, so others in a similar situation can benefit.