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?
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ infrastructure mailing list -- infrastructure@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to infrastructure-leave@xxxxxxxxxxxxxxxxxxxxxxx
