add comments on what to keep from the earlier version

remove duplicate footnote

Author: Xronophobe

chapter_09_docker.asciidoc

@@ -242,10 +242,6 @@ How will containerizing our software help with the danger areas?
 // TODO: consider getting rid of the staging server??
 
 
-
-////
-
-
 old content follows. is there anything we want to rescue from here?
 
 But there are solutions to all of these.  In order:
@@ -254,6 +250,7 @@ But there are solutions to all of these.  In order:
 *   Using a 'staging site', on the same infrastructure as the production site,
     can help us test out our deployments and get things right before we go to
     the "real" site.
+// CSANAD:  I would keep the staging server.
 
 
 *   We can also 'run our functional tests against the staging site'. That will
@@ -266,6 +263,12 @@ But there are solutions to all of these.  In order:
     like on our own PC, a 'virtualenv' is useful on the server for
     managing packages and dependencies when you might be running more than one
     Python [keep-together]#application#.
+// CSANAD:  I would keep virtualenv in containers. First, because it doesn't hurt and
+//          I have no knowledge of it resulting in any overhead. Second, because pip warns
+// against globally installed packages, and ignoring warnings is bad.
+// Finally, because it "feels" right:
+// my application is set up so that if I decide to switch over from containers to VM-s, I
+// don't really need to touch dependency management.
 
 *   ((("automated deployment", "benefits of")))((("automated deployment", see="also Fabric")))And
     finally, 'automation, automation, automation'.  By using an automated