[Originally sent Mon, 23 Dec 2019 09:51:27 -0500, but bounced due to a networking problem here with my Northeastern machine. You may notice that this is not a true reply, just a new e-mail with a subject line that looks like it is a reply. Sigh. Note that I will likely have trouble sending e-mail for some time to come.] So, it sounds like we should move the January Stylesheets group meeting to Tue 21 Jan 20 at 14:00Z. That is: 06:00 PST 09:00 EST 14:00 GMT 15:00 CET (Do we have any other time zones represented on Council?) Unless I hear strenuous objections pretty soon, we will plan on that. I am likely to miss the Council meeting of Tue 14 Jan 20 14:00Z. (I will be traveling in London; depending on train schedules, my family, etc., I may be able to make it, but I am not counting on it.) Whether I make it or not, I hope the topic of keeping the Docker containers updated is discussed. My thoughts on this topic follow, in no particular order. * It is definitely important to keep the OS running in a Docker container up to date with security patches. It may not be as big a problem as Martin worries it is, especially if we are all vigilant in leaving a container running for the minimum amount of time necessary. But it is still important enough that we should have a process for doing it. * The solution is probably administrative, not technical. * It is probably unfair to insist that Peter and Hugh be solely responsible for doing this. (That said, if they don't object, I don't either. I would if it were only 1 person -- at least 2 people should know how to do everything that is even semi-important.) Could be a rotating responsibility. * My suggested administrative idea: Once a month, 1-24 hours *before* the Council meeting, the Docker maintainer or designee should update each container with the latest OS security patches. (Chair should send a reminder 48 hours before the meeting.) Immediately *after* the Council meeting each Council member should download and install the updated container. * Peter pointed out that doing such an update might break the build within the container. He's right, but that's no reason not to install security patches. It's a reason to fix the build process so it works on a properly updated system. Doing this on meeting day, I figure, gives us a higher chance of noticing a build fail, finding a fix, and promulgating the solution rapidly.