I was disappointed with the response in the Configuration Management Initiative session with Greg Dunlap (heyrocker) when I asked a really important question — how do we deal with changes in production conflicting with what's in version control?
Consider the situation today, let's take a simple example: you configure a single pathauto pattern, create a Feature containing that pattern, push the Feature to prod, and enable the feature on prod. What if someone changes the pattern on prod? Now there's a conflict with the Feature that's in version control, and you can't revert the Feature or you will lose the update. I'm guessing roughly 99% of Drupal developers have faced this issue -- a Features page that says "Overridden" all the way down.
I asked Greg if he had given any thought to this problem, and his response was, "Disable prod access to /admin". Despite that remark being met with wild applause among the crowd, it's way too general — if not flat-out wrong.
Customers, especially enterprises where the release cycle can be long, really want prod access to /admin. Sometimes to move or add a block, sometimes to configure meta tags, there are scores of reasons why they want this. If we're looking for greater adoption among the enterprise, we can't ignore it. In the session I was cut off as I was trying to explain that at both large enterprises I've worked at that have adopted Drupal, AAA and PayPal, the ability to manage parts of the site live was a main factor in choosing the Drupal platform.
As developers we should realize that from an outward perspective, providing value for customers is our main (only?) focus. We should not cheer at the idea of keeping customers from doing what enables their business.
I'm pretty passionate about solving this problem, and I hope I can work with Greg and the rest of the CMI crew on this one.