The "regression" you're seeing here isn't necessarily a regression as such.
Each jumbo patch goes through a release process which includes testing, and
that testing time is based on a cut from the code tree at a fixed point in
time. 7.3.1, for example, doesn't contain all the fixes available on the
evening before its release. It contains the fixes available at the time the
release was cut; probably 2-3 weeks previously.
In reality, this is an attempt at producing higher quality software. Each of
the hotfixes which you can get patches for generally consist of the vanilla
release of the version which you have been using plus a snippet of code to fix
the issue you have been seeing. This snippet is taken in isolation from all
the other snippets of code which have been checked back into the code tree
since. The jumbo patch is the first attempt at compiling all of the fixes into
one release version. If bugfixes conflict and cause major issues, this will
hopefully be caught during testing.
In short, you should probably be *glad* that not all of the fixes are there.
If they were, you'd have a release with no testing against it. And you've seen
what 7.3 was like *with* testing..... 8O
Cheers,
Stuart.
________________________________
From: Legato NetWorker discussion on behalf of Stan Sander
Sent: Thu 22-Jun-06 16:00
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Subject: [Networker] Bug regressions?
I seem to have noticed on this list recently a couple of threads that
glaringly show examples of bug regressions within the Networker code.
I'm wondering how many of you have had to deal with this? It seems to
me that a software company would do everything in their power to ensure
that a bug that is fixed once is fixed for good. What I seem to have
noticed is that a particular bug will be fixed in a patched or hotfix
release for a limited number of customers that are experiencing it, but
then that fix is not rolled up into the next release whether that
release is a minor dot release or a major release. It appears to me
that EMC seems to think that bug regression is an acceptable business
strategy. Maybe I'm just being overly harsh or critical but I decided
to throw this out there and let the community on this list kick it around.
Here is just the latest example from another current thread on this list
that was posted by Oscar referring to auth failures when nsrmmgd starts
too quickly that Siobhan originally posted about:
> I can confirm this as well. We had this problem in netwroker 7.3, but it
> seems to have been fixed in the 7.3 jumbo patch, but since we upgraded to
> 7.3.1 it has occured again.
Sad state of affairs, IMHO.
(steps down from soapbox after a good rant, feeling much better....)
--
Stan Sander - CSU Special Projects (505)284-4915
ASAP, LLC, Contractor assigned to Sandia National Laboratories
Unix Systems Administrator
Microsoft: You've got questions. We've got a dancing paperclip.
To sign off this list, send email to listserv AT listserv.temple DOT edu and
type "signoff networker" in the
body of the email. Please write to networker-request AT listserv.temple DOT edu
if you have any problems
wit this list. You can access the archives at
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
To sign off this list, send email to listserv AT listserv.temple DOT edu and
type "signoff networker" in the
body of the email. Please write to networker-request AT listserv.temple DOT edu
if you have any problems
wit this list. You can access the archives at
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
|
