On 11/18/10, Maciej (Matchek) Blizinski <[email protected]> wrote: > No dia 16 de Novembro de 2010 21:18, Philip Brown <[email protected]> > escreveu: > > I think your contributions to the project in terms of examining > packages and discovering issues, are really valuable. I admire your > patience and insight. > > However, the 20 years experience argument leaves me unimpressed. I've > seen people with 15 or 20 years experience, who, when asked to write a > shell script, write something that doesn't work, and asked about the > big-O notation of the complexity of the script, can't work out the > answer.
I know what you mean. i've seen people like that. :-} usually been at the same low-level job for those 20 years. So let me share more detail of my experience, and how that benefits my position of release manager. In my 20 years sysadmin experience, I have worked in almost every segment of the IT industry. I have worked for 2 fortune-500 companies. I have worked for 3 'higher education' institutions. I have also worked for a silicon valley startup company. I have worked at places where the release process was "Go for it!". I have also worked at places where you were expected to file a full change management document, a week in advance, for any changes. I have worked in places where there were only 10 machines to deal with. I have worked in places where there are hundreds of machines to deal with. I have worked to support machines where the attitude was "eh, its okay to be down for a while". I have worked to support machines where the importance was, "If you screw things up, you'd better clear out your desk, because the company just lost $1million or more". I have also supported a wide variety of users. From the highly knowlegeable set, to the "Where's the 'any' key?" set And on a general computing competency note: I have a degree in computer science, and have had assorted chunks of code accepted into solaris... BEFORE the whole opensolaris source tree type access was started. So, there's where my judgement for package quality comes from :) > At the same time, the 20-years experience people are those who learned > to put up with crap around them, and would rather continue to do that, > instead of introducing change. It's the fresh people who notice crap > and have the energy to improve. So, if you want to reason from > experience, it works against you as well, experience makes you also > ill-equipped for making decisions. Erm... I think that a fair evaluation of my track record, shows that I am highly in favor of change: just so long as it is positive, well planed, and well managed change. *cough* I did bring network-enabled automated package installation to solaris, after all. Plus suggested the CAS framework. and worked on *some* of them,but then mostly stood back and encouraged other people to implement their own. And other things I'm probably forgetting. Summary: "change for change's sake=bad. researched and planned change = good" Most recent example: the pkg namelength change. I didnt block it just to block change. I wanted to make sure it was fully researched and thought out. And good thing I did, otherwise we'd have a 'new standard' that violated solaris capabilities, hmmm? > What I asked in the original question, was _how_ do you know what's > best for the user. I take my experience I mentioned above, and try to figure out how the package would best meet the needs of ALL the different types of environment and users if possible. If there's a fundamental conflict between "please these folks, or that folks", things get complicated. On the one hand, it may make no sense to deploy an application in one setting, so I ignore that segment if need be. But usually, I keep an eye more tuned to the "large, corporate style" usage cases. The reasons being: - Most people who work with "open source", have no idea of (nor do they even care to think about) impact to large scale deployments. Someone needs to plan it. - (From the user's perspective) It is easier to take clean methodology brought on by corporate deployment styles, and then deploy for a single user... then it is to take a lazy "it works good enough for me" single user oriented package, and then attempt to shoe-horn it into a large scale deployment. Most corporate folks who hit the latter style, will just say to themselves, "okay these guys are clueless/have no idea what they are doing... we cant trust them to provide packages for our needs", and give up on opencsw for any purpose whatsoever (whereas an individual user may not like one particular package, but use the rest of them) That is why I push particularly hard for large-scale-friendly packages. We cant grow OpenCSW to full potential, if we dont meet the needs of the large scale deployments well. Not only is this important as a general customer principle, but it also affects your interest in web search placement. "corporate worthy" sites, tend to get higher ranking. No corporate buy-in, means we lose writeups, and references. Which means we will be lower in search engine ranking than otherwise. _______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
