severity 865975 critical thanks My report just got merged into this one as a duplicate, so sorry for being late to the party…
On Tue, Nov 27, 2018 at 12:42:28PM +1100, Dmitry Smirnov wrote:
I'm lowering severity back to "important". You are not wrong that Docker is hostile to other applications but I think many users would agree that we need Docker in "testing" and upcoming Debian release despite of this problem.
With respect Dmitry, I don't think that this is an appropriate reason to lower the severity. I agree that we should ship Docker in Buster, even if we have not resolved this issue in time, since we couldn't introduce it after the fact, and it's an important and/or high-profile package. But the bug clearly meets the criteria for Critical severity: "makes unrelated software on the system (or the whole system) break": one can witness unrelated VMs lose networking in real time by starting the docker daemon and triggering the policy change. The proper way to try and ensure that Docker does not get dropped from Buster is to either fix the bug or request an exception from the release team (a "buster-ignore" tag). Lowering the severity to avoid triggering a removal is just hiding the bug from RC bug summaries and dashboards etc., violating SC §3 "We will not hide problems". I'm fairly confident that the release team would tag this buster-ignore. But, the preferred solution is, of course, to fix the bug. As Clint points out in [1], a solution is to ship a minimal conffile. On the face of it that seems like a simple solution, which has not been discussed by anyone else yet in the bug. I've tested the concept and it works, but needs cooking up into a patch. What are the caveats for this? At a minimum we would need a README.Debian too, I guess. [1] <20180104025648.eycf37gbzkxe7...@scru.org> -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄⠀⠀⠀⠀
