[tedreed]

As a sysadmin, I have to say that I hate Launchpad. I always have click many levels deep to find the thing I want. The interface just sucks.

I also know plenty of other sysadmins who use github but find no value at all in Launchpad.

Also: FWIW, I never notice folks' names on github. The important thing for me is that the code is right there front and center. If I want to download it, I click the clipboard button and then go clone it. Boom.

Edited to add: I also think that if it's not immediately apparent which fork is the "canonical" one, it probably doesn't matter. Just grab whatever looks most popular. If you decide you'd rather have a different one, then grab that later. shrug

[zedshaw]

> Also: FWIW, I never notice folks' names on github. The important thing for me is that the code is right there front and center. If I want to download it, I click the clipboard button and then go clone it. Boom.

Yeah, I think "BOOM!" is right. If you can't see the flaw in stuff like this:

http://drnicwilliams.com/2009/11/04/hacking-someones-gem-wit...

http://groups.google.com/group/gemcutter/browse_thread/threa...

Then you got no business being a sysadmin and working this way.

[tedreed]

I see a number of things discussed in those links. Could you clarify which you're referring to?

[Macha]

From my reading of it (disclaimer: I've only done a tiny amount with ruby) A package uses rubygem to install a-blah 1. This causes packages using require 'blah' that are not connected to rubygems to break if the a-blah installation overwrote an existing version of blah 1.1 (which you installed alongside said packages)

[tedreed]

Yeah, but I wouldn't install alongside. (Nor do I install anything via gem.)

[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.