[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.