jamessocol

I'd love to hear—maybe I missed another blog post—why they went with the single release manager, where only one person can merge and deploy. What happens if Doug is sick or on vacation? Or even just in a meeting? What is a typical amount of time for a change to sit in "ready for merge" or merged but not deployed?

Consider it? Definitely. But semver doesn't make a distinction, either, so it's a hard problem.

If you don't mind, we'd love to get your thoughts more via email--don't want to hijack this thread too much.

(Disclaimer: I'm the other guy behind BundleScout.)

The Django project does a fantastic job with announcements. (So does Rails.) And if every open source project had the infrastructure to make that much noise, the world would be a better place. But of the 100k or so Python/Ruby/NPM projects I know about, only a small handful do, or could even manage it.

And if they did, would you want to be on every one of their mailing lists?

Bleach, for example, has more users than I have twitter followers, so I doubt most of them heard about v1.2.1. (Out today! Go get it!)

> but it kinda sucks that you'd make people pay to hear about security issues

Well, like you said, there are other ways to hear about updates, at least from the big projects. This is the convenience of not needing to join dozens of mailing lists and/or check dozens of websites periodically.

Thanks for the feedback! We'll definitely look at the right way to surface more info before signing up. (For the record, it's $5/month.)

Thanks!

I agree with all of your advice about hardening most servers, but a couple of things...

> In the case of PHP, there is no security concern by it just sitting on your hard drive.

It's a surface area question. I could go into more details of the history of why it was there and configured (if you read further, you'd see that it was part of our puppet manifests, and for a reason). But you reduce the surface area of attack by reducing the number of things that can execute arbitrary code. And if you aren't using PHP at all, "yum remove php" saves you disk space and surface area, even if you have another colossal screw up (like we did).

> The most it could affect a user by itself is due to some temp file race someone might be able to take advantage of.

Well, the most it could do is, if you've screwed up someplace else, execute arbitrary code as the webserver user on the machine, thanks to the backtick operator.

Honestly, "easy to overlook" is why I wrote a checklist for basics. CYA, then get to the advanced stuff.