[csw-maintainers] Our core values: providing straightforward experience to the user

[rupert THURNER]

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 <phil at bolthole.com> wrote:
> On 11/18/10, Maciej (Matchek) Blizinski <maciej at opencsw.org> wrote:
>> No dia 16 de Novembro de 2010 21:18, Philip Brown <phil at bolthole.com>
>> 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
> maintainers at lists.opencsw.org
> https://lists.opencsw.org/mailman/listinfo/maintainers
> .:: This mailing list's archive is public. ::.
>