Remove the feeds module

content/node.862ba3ee-9c27-40e6-9e86-a5ce4c1bae67.json

@@ -87,14 +87,5 @@
             "processed": "\n          <p>I previously worked on a project where, after a code change had been reviewed and merged, it was pushed to a UAT environment for the client to test.<\/p>\n\n<p>This usually resulted in a group of changes pushed to the UAT environment, waiting for the client to test them.<\/p>\n\n<p>They would, and then decide which changes they wanted to be moved to production.<\/p>\n\n<p>Maybe changes 1, 2 and 4 would be asked to be deployed, but not 3 or 5.<\/p>\n\n<p>Someone would then cherry pick the relevant commits onto the mainline branch and deploy them to production.<\/p>\n\n<p>But, if the code isn't the same as on that UAT environment, how do you know it still works?<\/p>\n\n<p>Could a commit have been missed or could not including a non-selected commit have caused a regression or unintended side effects?<\/p>\n\n<p><code>git cherry-pick<\/code> isn't a command I use often, and definitely not in this scenario.<\/p>\n\n<p>If you want to select which changes go live, feature flags are a better option as you don't need to change the commits or code you're pushing.<\/p>\n\n<p>You push all the commits from UAT to production and enable the feature flags for the things you want to release.<\/p>\n\n        ",
             "summary": null
         }
-    ],
-    "feeds_item": [
-        {
-            "imported": "1970-01-01T00:32:50+00:00",
-            "guid": null,
-            "hash": "bbdb6758f1c4bd5875133b5b5a4314a5",
-            "target_type": "feeds_feed",
-            "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
-        }
     ]
 }