HP3000-L Archives

February 2001, Week 4

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
John Clogg <[log in to unmask]>
Reply To:
John Clogg <[log in to unmask]>
Date:
Fri, 23 Feb 2001 11:00:47 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (33 lines)
I will typically avoid at all costs the installation of a new release until
PP1 is available, for the reasons already stated, and prefer to wait for
PP2.  Obviously, it depends on the addition of needed/desirable
functionality.

As has been pointed out, one tends to accumulate a lot of boxes containing
tapes that will either never be used, or won't be used for a long while.  I
have been known to just call the Response Center and request a new set of
tapes rather than trying to figure out which ones to use.  HP seems to have
the right idea with those mailings that include a fax-back form for ordering
the tapes.  The only problem is that most of them have time limits (You must
respond by xx/xx/xx), so one tends to order the tapes even if they have no
immediate plans to use them.  For a push release, a similar form, with no
time limit, that said "Send this in whenever you are ready to install this
release, and we'll send you this release plus the latest PP level and
recommended reactive patches" would be a great solution.  This process might
also vary depending on support level.  CSS customers usually receive
periodic patch reviews, so perhaps the release process could be somewhat
customized for them.

Regarding the life-span of a release.  Most have voted for "as long as
possible".  While I tend to agree with this position, it does conflict
somewhat with the desire for MPE to be up-to-date with respect to
industry-standard tools and hardware interfaces.  HP obviously has a need to
limit the number of supported versions to a manageable level, while we
customers demand both timely improvements and stability.  The practice of
"platform releases", i.e. releases that will be supported for a long time,
is a good one that could be expanded.  I would like to see platform releases
supported a bit longer than they have been, with a substantial overlap
between them, in order to allow the new platform release to become stable
before being forced off of the old one.  The releases between major platform
releases could have a shorter support life.

ATOM RSS1 RSS2