I just remembered that I had never upgraded production to version
2017.0:
https://github.com/fedora-infra/fedmsg-atomic-composer/releases/tag/2017.0
This means that if I install 2017.1 (which has the 1-char diff I asked
for an FBR on) it will also be installing those changes.
FWIW, most of those changes are already hotfixed on production, and
2017.0 was primarily made so that we could have a real release on
production rather than a "sudo vim"'d release. There are a couple of
changes from those release notes that I don't think are on production:
* AtomicConsumer now has a config key
I think this one will also stop some e-mails we get when fedmsg-hub
is restarted.
* stderr messages are now logged at info and not error level
This one is where I introduced the exit code problem that my FBR is
supposed to fix, but note that without this change all stderr was
logged as an error which is incorrect since many programs use stderr
for debug/detail statements (including rpm-ostree as we are seeing).
2017.1 corrects this change to correctly use the exit code.
With this info, are you still +1 on deploying 2017.1 (with the 1-char
diff)? I personally think it's still OK to go, but I wanted to be
forthcoming about the present state before making more changes than I
had written about in my original FBR. If not, some other options:
* We could wait until after the freeze.
* I could continue the tradition of "sudo vim"'ing production and just
change that log statement to info instead of error.
What say you?