I'll be much more succinct than Matt, though I agree with the bulk of his
message.
1) Don't re-use patch numbers. If you have to fix a patch, the two patch
(n)s are not the same. I understand why it's done the way it is now, I just
disagree with it, having been bitten hard by having multiple versions of a
particular patch differentiated only by the download date. Currently, it's
hard to know whether I have the good patch or the bad one until after I
install it.
2) Be MUCH more clear in what is changed in each patch. Given that
customizations have to be re-done, it would be REALLY nice to know WHICH
customizations need to be redone. The only way that's happening is to see a
list of all of the workflow objects that the patch is modifying, so that we
can compare it to our list of customizations. In short, provide us with the
same level of information that we have to provide to our Change approvers
and Managers, instead of making our jobs harder by having to trash a test
server just to figure out what BMC did, and how to clean up after it.
Thanks for asking, and for listening.
Rick
On Wed, Sep 10, 2008 at 8:32 PM, Carey Matthew Black <[EMAIL PROTECTED]>wrote:
> David,
>
> I will bite on this discussion. (Note- I am a long time customer here.
> I am not trying to shot the messenger, but the messenger offered to
> converse with us... So... here we go.)
>
>
> I think the whole problem is the difference between revision and
> version(or build) numbers. I can understand how some non-programmers
> can get confused about these ideas. However, BMC should be able to
> help their customers Admin/Developers understand the difference.
>
>
> - Enter my definitions -
> Note: I think these definitions are not limited to "just me". I think
> they are fairly commonly held ideas. (But I could be wrong. If I am, I
> am sure someone from ARSList will point that out. :) )
>
> Every time a developer changes anything about any file that roles up
> into one or more product/part/widget(s) that sounds like a revision
> number increment to me. (and the revision number schema should really
> only depend on your internal source control system. Ideally, that
> could still be visible to end customers, but maybe only for diagnostic
> reasons.)
>
> When the vendor decides to take the current "best we have" set of
> files and stamp it with a new "version number" then that thing as a
> whole (AKA: a build) is the sum total of the whole ball of wax of
> those widget(s) that they are going to be selling as version "X".
>
> Version numbers should be (IMHO) "Major.Minor.Patch". ( BMC uses
> something slightly longer than that.)
>
> A patch should have a defined, and published, "base"(starting point)
> that it can be applied too.
>
> Remedy's "base" has always been "any previous version".
> So the patch gets you from where you are to the version your
> patching too. (That is just a simple mater of history.) If you are
> running v4 then go install v7.1 on top of it. The patch/installer
> should do each upgrade between 4 to 5 to 6 to 6.3 to 7 and finally to
> 7.1. Ok... Ok... So v4 to v7 really is not supported due to the
> limit on the number of major releases that the patch/installers will
> be supported to work on. ( Yea.. I understand that.) But you can go
> from v4 to v6.3 then run a second installer to go from v6.3 to v7.1.
> However, the idea is that _any supported version_ should be a valid
> start point for the supported patch/installer.
>
>
> I believe there is no need to have all independently sold products to
> be released for every minor or patch version. However, the thing that
> is sold as a "Quantity 1" should be internally consistent with all of
> it's parts at all releases (Major, Minor AND Patch).
>
> I believe there is no need to have all "version 'x'" releases be
> compatible with each other across independently sold products. (But
> that can be a nice to have condition for marketing reasons.)
>
> - Exit my definitions -
>
>
> In your example... lets talk though a specific existing example ( with
> a few more releases between the start and stop versions)...
>
> There are documented problems with only upgrading some components
> across some patch lines. Like between 7.0.01 patch 003 and 7.0.01
> patch 004. Presumably all of the affected parts were patched in
> "7.0.01 patch 004", and would be in that patch. But what about the
> customer who a jumps from "7.0.01 patch 003" to "7.0.01 patch 009"?
>
> NOTE: All referenced data below was acquired from the "patch download
> site"('Area' field) and only slightly reformatted to try to align the
> part in the patch into a consistent order. Some of the abbreviations I
> did not try to expand because I thought they were to ambiguous.
>
> Patch 003: Server, Admin Tool, User Tool, Email, Web, Approval, Migrator
> Patch 004: Server, Admin Tool, User Tool, Email, Web, Migrator
> Patch 005: Server, Admin Tool, User Tool, Email, Web, Approval, Migrator,
> Assig
> Patch 006: Server, Admin Tool, User Tool, Email, Web, Approval
> Patch 007: Server, Admin Tool, User Tool, Email, Web, AS, AE, Flashb
> Patch 008: Server, Admin Tool, User Tool, Email, Web
> Patch 009: Server, Admin Tool, User Tool
>
> So I want to point out that:
> ) "7.0.01 patch 009" only patched a few of the components patched in
> Patch 4. (Missing: Email, Web, and Migrator)
> ) there were additional components patch in other patches (like
> patch 007) that were also not "patched" in 009
>
> So if a customer jumped from Patch 003 to Patch 009... they would not
> get upgraded patches for...
> Email, Web, Approval, Migrator, Assig, AS, AE, Flashb
> That would leave them with a Mid-Tier = Patch 003 and an ARS
> server Patch 009. A combination that has known problems.
> That sounds like a really bad condition to me.
>
> And I want to point out that if you look at patch 004's download
> directory then you do see the Approval Server in the patch 004. Even
> though it is not identified as part of patch 004. (Which is the way it
> should be. Because the Approval Server is no longer the FCR it is
> Patch 003. Well, or it was patched and the list of things patched in
> patch 4 is wrong. Which after reviewing the Read me suggest that a bug
> was fixed in the Assignment engine in patch 004 and the list of items
> patched is wrong. Drat. I hoped that would be a good example of how
> BMC Remedy "use to do it right". Oh well.)
>
> FWIW: Patch 009's download directory only has the Server, Admin Tool
> and the User Tool.
>
>
> As you have described the current condition of BMC Remedy patch
> process.... I also wonder if the "installers" ( that are part of the
> released patches) are possibly just as "lacking" in some parts of
> those things that are being installed? Can a customer be certain if
> Approval Patch 005 actually has all of the Patch 003 code in it? ( I
> have seen bugs return in a "skip one, or two patch versions" pattern
> before.)
>
> It really means that a customer has to read/check/analyze all patches
> between the release they are using and the release they are going to
> move too. ( That really seems silly and error prone to me. )
>
> If that is how BMC think software release should be done, then there
> should at least be a small tool (AKA: An ARS form) that can be used by
> the customers to identify "Start at version", "End at version" and
> "You have these things installed on the server".. --> "Here is your
> list of what patch(es) you need to install and the order they need to
> be installed so you can get there."
>
>
> But maybe it is just me.....
>
> --
> Carey Matthew Black
> Remedy Skilled Professional (RSP)
> ARS = Action Request System(Remedy)
>
> Love, then teach
> Solution = People + Process + Tools
> Fast, Accurate, Cheap.... Pick two.
>
>
>
> On Wed, Sep 10, 2008 at 3:45 PM, Easter, David <[EMAIL PROTECTED]>
> wrote:
> > (Note - I am the messenger here)
> >
> > Currently, patches are "cumulative" for a given component within a patch
> > - however, if a component is not modified in a patch, then it is not
> > included in that patch. For example (and this is a made up example):
> >
> > Patch 001 - User Tool, Mid-Tier and Server changed. Patch includes
> > folders for User Tool, Mid-Tier and Server
> >
> > Patch 002 - User Tool, Mid-Tier and Assignment Engine changed. Patch
> > includes folders for User Tool, Mid-Tier and Assignment Engine. User
> > Tool and Mid-Tier changes also include any changes done in Patch 001.
> >
> > Patch 003 - Mid-Tier, Assignment Engine and Server changed. Patch
> > includes folders for Mid-Tier, Assignment Engine and Server. Mid-Tier
> > also includes changes done in Patch 002 and Patch 001. Assignment
> > Engine also includes changes done in Patch 002. Server also includes
> > changes done in Patch 001.
> >
> > etc...
> >
> > So in this case, you'd need to install Patch 002 and 003 to get the
> > cumulative updates to each sub-component. You wouldn't have to install
> > Patch 001 because everything in Patch 001 (User Tool, Mid-Tier, Server)
> > was cumulatively updated in a later patch.
> >
> > With the newly developed installer being tentatively aimed for AR System
> > 7.5.00, BMC may have a chance to re-visit this approach. I'd certainly
> > be interested in the dialog around this if you all wish to discuss it.
> > Here's some points to consider:
> >
> > 1. Some consider "cumulative" to mean inclusive of all patches prior -
> > even those components that have not changed.
> > 2. However, including things that haven't changed from the last patch
> > could cause testing organizations to question that "nothing changed" and
> > therefore force a retest the component (and incur that expense)
> > 3. Some customers do not install the base product and then patch - they
> > go to the patch site and install the latest patch since it (typically)
> > contains every component needed. Knowing that a patch doesn't always
> > contain every component, sometimes this may require the installation
> > individual to get multiple patches to get all of the components.
> >
> > Other points, I'm sure, exist as well.
> >
> > Thanks,
> >
> > -David J. Easter
> > Sr. Product Manager, Solution Strategy and Development
> > BMC Software, Inc.
> >
> > The opinions, statements, and/or suggested courses of action expressed
> > in this E-mail do not necessarily reflect those of BMC Software, Inc.
> > My voluntary participation in this forum is not intended to convey a
> > role as a spokesperson, liaison or public relations representative for
> > BMC Software, Inc.
> >
> >
> > -----Original Message-----
> > From: Action Request System discussion list(ARSList)
> > [mailto:[EMAIL PROTECTED] On Behalf Of Axton
> > Sent: Wednesday, September 10, 2008 12:01 PM
> > To: [email protected]
> > Subject: Re: FBserver not in AR 7.1 patch 3
> >
> > Patches are supposed to be cumulative though. If fb was in patch 2, I
> > would expect to see it in patch 3.
> >
> > Axton Grams
>
>
> _______________________________________________________________________________
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
>
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
