[c-nsp] Questions on open caveats for 6500 IOS (12.2(33)SXJ train

[chris stand]

I would like to point out that feature navigator updates are seeming
to be more closely available when new releases of code are available .
 This used to not be the case.

thanks.

> Message: 7
> Date: Wed, 27 Jun 2012 11:31:00 -0500
> From: Andy Ellsworth <andy at dar.net>
> To: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] Questions on open caveats for 6500 IOS
>        (12.2(33)SXJ    train)
> Message-ID:
>        <CAMGH26kBS4yxQ_kHX2Q8wwV3UOQtoDxyGm2+fg048EPU-u7ByA at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Tue, Jun 26, 2012 at 10:31 AM, Phil Mayers <p.mayers at imperial.ac.uk> wrote:
>> In short - take it with a big pinch of salt, and don't rely on it.
>
> Thanks for the feedback. The Cisco development engineer I just spoke
> to essentially confirmed this - the open and resolved caveat lists in
> the release notes are automatically generated, and are therefore only
> as good as the metadata in the bugs.
>
> Focusing on one example (CSCsm59426), he was able to look at the
> source code and confirm that the bug was in fact fixed in the SXJ
> train, but simply not marked as fixed in that version due to an
> oversight in the sequence of forks/commits that led from 12.2 to
> 12.2SX to 12.2SXJ to SXJ3.
>
> He hinted at some internal improvements in the pipeline that will add
> additional intelligence to the bug checking process - improvements
> that might actually propagate to the bug navigator (and thus improve
> the accuracy of caveats listed in the release notes). Until that
> happens, if you've got enough leverage, it's possible to arm-twist
> Cisco into checking specific open caveats you may have red-flagged to
> determine if they are actual bugs in the train you're reviewing.
>
> -Andy
>
>