there lies a lot of truth in all these mails. for us the incentive was: 1. simple way to get a 2. stable solaris package which comes from a 3. long time sustaining (most important!) project which has a 4. simple way to create a package which allows an 5. effortless update to a new upstream version
because it is early in the morning, allow me to be a little provocative: as so many emails are written, somebody must have some spare time, which is a very good sign for an active voluntary project :) who helps me updating php to a new version, maybe make the package less complex ? rupert. On Thu, Nov 18, 2010 at 19:07, Philip Brown <[email protected]> wrote: > 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. ::. > _______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
