[j-nsp] EX4200 9.4R2.9 process crash on previously valid config

[michael.firth at bt.com]

> -----Original Message-----
> From: juniper-nsp-bounces at puck.nether.net 
> [mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of Mark Tinka
> Sent: 03 April 2009 02:58
> To: juniper-nsp at puck.nether.net
> Cc: Richard A Steenbergen
> Subject: Re: [j-nsp] EX4200 9.4R2.9 process crash on 
> previously valid config
> 
> On Friday 03 April 2009 09:14:28 am Richard A Steenbergen 
> wrote:
> 
> > Dare I ask who you're defending here? In all honesty,
> > with respect to the quality and time/attention that goes
> > into the software development and QA process of new
> > software, JUNOS has gone massively down hill lately.
> > Anyone who expects that a bug fix R1->R2 build is not
> > likely to introduce some massive new issue in something
> > that was previously working fine clearly hasn't been
> > deploying JUNOS over the last year.
> 
> I realize that Juniper have to make a new release every 
> quarter, and in most (if not all) cases, there is some new 
> feature which has the potential to cause "badness" to 
> systems that are already working fine.
> 
> I think what I'd like to see is a fork of the code base 
> which consolidates all new features up until that point, and 
> then enters into a maintenance state - only bug fixes, with 
> no new features.
> 
> Other iterations of the code would continue to come out with 
> new features every quarter.
> 
> I realize this is entering Cisco territory, but given that 
> each new release of JunOS has new features that could 
> potentially cause problems, and previous bugs still go 
> unfixed (priorities?), I don't see a better way to have 
> stability if we keep chasing bug fixes in new releases that 
> lead to newer bugs we keep chasing fixes for in even newer 
> releases, e.t.c.
> 
Isn't that what the JunOS EEOL (extended end of life) releases
should be (or more probably could be)?

Juniper already have these releases they guarantee to support for 3 years.

All (!?) they would need to do is to release more 'R' releases of those
versions than they currently do, rolling all bug fixes that are going 
into new releases into the EEOL releases too.

I agree with you that this would keep a lot of their customers happier - 
particularly with the expensive hardware uplift (new CF and RAM for every
RE) that's needed to go from 8.5 to 9.x.

I personally would be happier with the release cycle being halved - if a
new release only came out every 6 months, but each release was better tested
and supported, then I think the end result would actually be a better product.

Currently the general opinion is that an 'R1' release is usually too unstable
to be usable, which means that there isn't really a usable release happening
every 3 months anyway. Slow the whole release process down, and there'd be a lot
more time to test things properly.

Regards

Michael