Recently there has been a few postings on 3000-L regarding Patch/iX
and the fact that Patch/iX does not "automatically" qualify
"enhancement" patches.

I have explained, in other postings, that this is the way the product
is designed. I have further explained that this feature was
specifically included based on feedback from the various "customer
partners" that participated with the Patch/iX development team during
the devolpment of Patch/iX.

In case you have not read those other postings, this is a summary of
why Patch/iX is desgined to work the way it does.

Many customers are "risk adverse" when it comes to managing there
systems (in general), and by extension of this philosophy, they are
also "risk adverse" when it comes to installing patches.

Prior to Patch/iX, the only tool that was capable of installing a
PowerPatch tape was AUTOINST. One of the main shortcomings that
customers identified with AUTOINST was that it was "all or nothing".
Specifically, AUTOINST will qualify patches (using essentially the
same code as Patch/iX), but AUTOINST does not give the user any
control over which of the qualified patches it will install. The only
choices the customer/enduser has is to install all of the qualified
patches, or no patches at all.

Customers said they wanted to have more control over which patches
should be installed. One of the reasons they indicated they wanted
this control was so that they could not install patches that they did
not want. The felt that installing unecessary patches was adding to
the risk, and this in trun decreased there willingness to install
patches proactively.

Taking this logic one step further, these same customer partners
indicated that they wanted to be albe to differentiate between
patches that were for "bug fixes" and patches that were for
"enhancements". The "risk adverse" group did not want enhancement
patches to be installed (by default). They felt that if they wanted
"enhancement" patches they would be happy to "ask for them".

The Patch/iX team implemented this concept by having the patches
having "enhancement" patches not qualify. The user can investigat the
cause for the patch not qulifying, and if the sole cause was that it
was an enhancement patch, the customer can "force" the patch.

Investigating the cause for a patch not qualifying, and "forcing" a
patch are things that a skilled user of Patch/iX should know how to
do. (At least this was the what the developers of Patch/iX thought.)

What I am asking for is specific feedback that helps us (HP) to
decide if this behavior is correct for the masses.  It would be easy
to look at the recent 3000-L posting and say "NO, this is not the way
is shoudl work". But please think about your reasons considering what
the orginal customer feedback said and what the developers of
Patch/iX were trying to accomplish.

Q: Should Patch/iX differntiate between "enhancement" patches and
"bug fix" patches?

Q: Should the default behavior be to not install "enhancemnt"
patches?

Q: How should the funtionality be present to the enduser to be
maximally clear and maximally "safe"?

Please explain your reasoning in detail...I need to understand your
logic and assumptions.

Please feel free to post your reasons to either the 3000-L list or to
send them to me directly. I will take this feedback into account in
deciding what (if anything) to do about the "issue" -- and when
prioritizing this against other potential fixes/enhancements for
Patch/iX and Stage/iX.




                                 Scott McClellan
     ___   ___   _________       Hewlett-Packard
    /_ /| /_ /| /_______ /|      Commercial Systems Division
   |##| | ##| ||########| |      19447 Pruneridge Ave
   |##| |_##| ||##| |_##| |      Cupertino, CA
   |##|/__##| ||##|/__##| |
   |########| ||########|/       E Mail: [log in to unmask]
   |##| | ##| ||##| |            Phone : (919) 969-7870
   |##| | ##| ||##| |            Fax   : (919) 969-7871
   |##| | ##|/ |##|/
    --    --    --               Voice Mail : 447-6067