> On May 23, 2013, at 8:36 AM, Mikael Abrahamsson <[email protected]> wrote: > > On Thu, 23 May 2013, Jared Mauch wrote:
> That seems to be what the SE in the (now trimmed reference) was suggesting. > I understand not everyone has lab/test hardware, but if that's the case how > can you ever upgrade anything without risk. At some point you need to make > that jump. you wait until the "big ones" run the image, assuming they have done testing. If the SE has the right connections s/he should know which images went through EFT. Of course you still don't know if the features "they" use are the same you will use - you may hit different bugs. Only alternative: you test yourself. Actually is anyone rolling out new software without some basic lab tests at least?! > > It seems more imperfect shortly after release than after a while. you mean after a while you have some SMUs? Or at least you know about more bugs? The software is not like wine, getting better the longer you keep it in the cellar ;-) > Without the vendor getting feedback that their software is good (or bad), > they are left with an unknown outcome for their software release. The main external feedback comes from larger customers testing the software, using EFT images, i.e. before the image goes public on CCO. Once the defect is out in the wild it's a bigger problem. Producing a SMU is relatively expensive, you keep a good number of engineers busy for weeks re-evaluating the SMU. Which is why you may see a certain, erm, reluctance. > > Me neither. I get very upset when they say that they won't fix things in > > 4.2.3 (which is supposedly a long-term support release) and they usually > > fix it. I take for granted that I'm not the only upset one. > > I'm can get very frustrated with Cisco on these topics. We went a round with > them on 4.2.2 as we depended on that release for specific hardware. They > didn't want to support it. If that's the case, there was no point of the > release at all, why even ship that release? (can you feel my frustration? :-) See above. SMUs are a permanent struggle. And hey, what about 4.2.4? ;-) > >> But rejecting something with loads of bug fixes and architecture changes > >> to fix the whole every smu is a reload one because of a calendar without > >> defects is irrational and illogical. > > > > I don't really understand what you're trying to say here. A new image may have new bugs, mainly due to new features. But it also has bug fixes. Don't think you see all of them in the Release Notes - some of these "bugs" never show up, not even internally. > > Anyhow, I apply the same logic here as I do in IOS-land. You start to get > > on 12.0(32)SYx when X is above 3 or 4. Same with SRE for 7600, SRE4-5 or so > > started to be ok. Not exactly what IOS-XR is doing. At least the number of new features in 4.2.x or 4.3.x is decreasing with increasing x. But it's not just bug fixes. Regards, Marc _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
