Re: [j-nsp] Junos 21+ Killing Finger Muscle Memory...
Indeed. And as you’re alluding to and most probably already know this — yeah most of us end up settling on “some release train” for a while, after we spend 3-4 months testing it thoroughly in the Lab... then spend 18 months getting everything in the network “up to that release”. With hundreds of beefy devices spread across the globe, and having to do customer notifications to each and every service, (and get them to also agree on the time that we’re doing it.. some of my customers have a LOT of weight, and can say ’no’), it does take quite a while to get through it all. And yup - by that time, 2+ years has gone past, and it’s time to do it all over again. Lather, rinse, repeat. ;) FWIW — The last one I personally did testing on for our LAB and production network was 20.4Rx-Sxx (EEOL version)….. so yeah, we started running into this new “sh[tab] rou[tab]” command in the Lab in the last few months as we started our tests on 21.4 and 22.4 (the next EEOL candidates for a global rollout) It is what it is. ;) My hope is that it’s ‘not too late’ to fix this slightly-annoying UI/UX experience and this can be pulled back from the jaws of defeat before it gets entrenched too far. as Mark said, If it gets looked at, great. If it doesn't, it's not the end of the world; but if we, as customers, don’t provide useful and constructive feedback to Juniper (something they’re asking fro with their outreach programmes, the Elevate community, the Juniper circle, etc..) then it has a 100% chance of never getting looked at. - CK. FWIW — The contrarian position would be if I were to simply just blindly install “oh hey, theres a new JunOS” every 3-4 months, and we get a nasty VPLS bug, or an eVPN bug, or an HQoS Bug, or an ISIS/SR bug which causes an outage/customer issue, I’d quickly find myself with a pink slip. ;) > On 16 Jul 2023, at 4:54 am, Crist Clark via juniper-nsp > wrote: > > I find it kind of telling that customers are just getting around to > complaining about it two years after it was released. Not at all > surprising, but illustrates how slow network operators update cycles can be > compared to the pace of development. > > To the Junos developers, this is ancient news, long forgotten in the dozens > of sprints and multiple releases since. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Junos 21+ Killing Finger Muscle Memory...
On 7/15/23 20:54, Crist Clark wrote: I find it kind of telling that customers are just getting around to complaining about it two years after it was released. Not at all surprising, but illustrates how slow network operators update cycles can be compared to the pace of development. To the Junos developers, this is ancient news, long forgotten in the dozens of sprints and multiple releases since. While I do take your point, to be fair, this is one of those things operators are not likely to complain about because it would be coming from a place of priviledge. There are far more pressing issues than this, to be honest. So like us who have been running Junos 21 for the past 8 or so months, we've been struggling with this and have been meaning to bring it up. But it's not a major catastrophe, so we haven't prioritized - and this post is really tongue-in-cheek. If it gets looked at, great. If it doesn't, it's not the end of the world. If you run a network of significant size, you are going to be in a constant cycle of code upgrades. So it's not unreasonable to find operators being behind. Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Junos 21+ Killing Finger Muscle Memory...
I find it kind of telling that customers are just getting around to
complaining about it two years after it was released. Not at all
surprising, but illustrates how slow network operators update cycles can be
compared to the pace of development.
To the Junos developers, this is ancient news, long forgotten in the dozens
of sprints and multiple releases since.
On Wed, Jul 12, 2023 at 2:13 PM Andrey Kostin via juniper-nsp <
juniper-nsp@puck.nether.net> wrote:
> Hi Mark,
> 100% agree if it could help.
> Very annoying. If UX designer touched it, he or she probably never
> actually worked with Junos.
>
> Kind regards,
> Andrey
>
> Mark Tinka via juniper-nsp писал(а) 2023-07-12 04:49:
> > So, this is going to be a very priviledged post, and I have been
> > spending the last several months mulling over even complaining about
> > it either on here, or with my SE.
> >
> > But a community friend sent me the exact same annoyance he is having
> > with Junos 21 or later, which has given me a final reason to just go
> > ahead and moan about it:
> >
> > tinka@router> show rout
> > ^
> > 'rout' is ambiguous.
> > Possible completions:
> > routeShow routing table information
> > routing Show routing information
> > {master}
> > tinka@router>
> >
> > I'm going to send this to my Juniper SE and AM. Not sure what they'll
> > make of it, as it is a rather priviledged complaint - but in truth, it
> > does make working with Junos on a fairly historically commonly used
> > command rather cumbersome, and annoying.
> >
> > The smile that comes to my face when I touch a box running Junos 20 or
> > earlier and run this specific command, is unconscionably satisfying
> > :-).
> >
> > Mark.
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
