[lug] Request/bug tracking systems--suggestions for small team

[Nate Duehr]

Jeffrey Haemer wrote:

> My advice?  Find a tool you like and that does a reasonable job solving 
> your problems.  Get comfy with it and use it until you have a compelling 
> reason to switch.  But don't freak when you do switch and things work 
> differently at first.  Listen to folks who are passionate about their 
> tools, but don't assume they're right if they say, "You can't possibly 
> do X with Y."  Even when that person is yourself.

Or don't even entertain such discussions about a switch of tools without 
someone writing a compelling business case that shows switching will 
either save money, increase efficiency, or improve security... and even 
those are all debatable "benefits" versus the chaos of a switch of 
tool-sets.

Also have them cover the training and hardware upgrade costs out of 
THEIR department's budget.

Tool-zealotry dies quickly under such real-world business scrutiny.

Make their managers decide that something is truly better for the 
BUSINESS as a whole, before deploying anything, and then give them 
reasonable data and at least two options if they ask for help making 
that argument.

Great way to remain a trusted partner with your bosses for many MANY 
years, if you're a sysadmin.

Changing things because someone says the newer version of something is 
"better" without proper business analysis, is a recipe for SOME sort of 
revenue loss disaster, even if it's just your example where a single 
developer deletes his/her whole source tree and forces the admin to 
spend time recovering it from backups... everyone has backups, of 
course... and they're tested and working at all times, of course.  ;-)

Example:  Most telco systems still run Solaris 8.  Sure there's nifty 
toys and tools for the admins in Solaris 9 and/or 10... but there's zero 
compelling BUSINESS need to upgrade these boxes.  If it would save 
significant time/money to upgrade them, these companies would -- but 
they can't find good reasons to take downtime on production systems and 
plan heavy upgrades that are more intrusive on getting business done 
than they are positively going to provide new benefits to their 
organizations... so they run Solaris 8, and force Sun to continue to 
write service contracts on it...

Sun's role would be to build something SO COMPELLING into Solaris 9 and 
10 that companies NEEDED to upgrade to it.  They didn't.  New 
deployments, fine... systems that have uptimes measured in years... 
nope.  Not worth it.

Same thing happens with Linux... upgrade/security patch cycles were too 
fast on some of the fancy distros that spun out of Debian (which people 
complain is too slow to roll major version releases)... so Ubuntu as one 
example, drove business people crazy... Fedora also purposely uses this 
tactic to force businesses to RHEL (and usually to CentOS instead, if 
they don't want to pay for RHEL)... 6 month major releases, and quick 
deprecation of older versions.  Businesses don't like that.  Ubunutu 
came out with LTS (Long-Term Server) versions, Fedora has RHEL... and 
CentOS.

All this fussing around with release cycles the last couple of years by 
all these distros (others like MEPIS, and quite a few others have also 
gone through this merry-go-round)... and meanwhile Debian's cycle sped 
up only slightly and still meets the business and end-user needs.

Kinda funny and ironic, really.  Devs tried to speed releases up and 
drop "not-very-old" releases faster, and the real world rebelled.  Not 
much of a surprise there, honestly.

Nate