[bradleyland]

I definitely live more in the sysadmin camp than the programmer camp, so I can see exactly what you're saying without even reading the links.

A programmer is prepared to dive deep. The programmer writes tests that validate their assumptions at ever level. The programmer lives intimately with their project.

Contrast this to the sysadmin. The sysadmin lives wide. He/she has to support many developers and many applications. These days, it's popular to use virtualization to isolate applications in their own little world, but it's also horribly inefficient. I love virtualization because it lets me get the most out of my hardware, but as a responsible sysadmin, I group applications in ways that make sense, rather than firing up a bare bones container for every app. This means that I must maintain some sense of consistency and order in the environment. Imagine the sysadmin's frustration when every programmer they work with thinks it's ok to grab any randomly forked lib from Joe Blow's GitHub repo and expects the sysadmin to integrate it in to the environment. It's a change management nightmare.

Being a sysadmin is about fostering stability and consistency. The server must be up. Apps must be up. The sysadmin's job is to make sure those two conditions remain true, and the "fork and go" mentality makes it a nightmare.

[tedreed]

I'll agree to some extent about the consistency, but I don't think that the "fork and go" mentality makes stability any worse.

I mean, as it is, I see segfaults and whatnot regularly in the canonical, distro-released versions of Apache. Major software releases all the time with bugs that could potentially be a show-stopper. My experience hasn't shown this to be any worse with non-canonical sources. Sometimes it's better.

Further, I like to think of the sysadmin's job as fostering business continuity. While uptime is a primary indicator of this, I think it's lower in priority than say, losing a crapload of customer data. If I have to shut a site down for an hour to prevent losing all transactions for the previous 24 hours or something, then it's not a terribly difficult choice. (Having to make this choice at all, of course, means you should be engineering something better. But we don't have the luxury of infinite time.)

And having all the uptime in the world won't help you if your engineers can't do their jobs effectively because the tools you give them are insufficient. Sometimes the best option is to suck it up and try that patch.

It's a delicate balancing act, and I'm not by any means advocating running all your software out of unofficial repos. Sometimes you gotta make that call, though. And if I'm looking at github at all, it's probably because a package doesn't already exist, or because I need a fix for one specific bug.

[kunley]

Even worse nightmare is pretending that the code is more stable just by labeling it as "package vX.Y.Z" and hiding the actual meat behind such "profesionally" looking cortain.

And yes, I'm an admin for 15 years.

My experience is when software is bad, it's just bad. No packaging system will help it. If I have a suspicion it's bad, I want to see quickly just how bad it is and check if I can repair it in half of an hour or drop entirely. Github helps with such decision greatly.

[bradleyland]

I'm not making the argument that giving a package a static label makes it better, I'm arguing that it makes it more consistently identifiable. When you're trying to figure out what's breaking your system, consistency is the key to isolation.