The New Canon EOS R6 firmware v1.3.0 has been pulled globally

[[email protected]]

Canon had indicated it wanted to up the cadence of its firmware releases, perhaps even going monthly. Reality is hitting, and this update was supposed to see light a bunch of weeks ago. There were probably worse, more obvious bugs that they fire-drilled on, and this was missed. Fast cadence software development usually means accepting higher risk on testing, knowing you have a follow-on update a few weeks later. The firm I work for is as guilty of this as anyone. This usually - but not always - makes companies a bit more lax in initial testing, perhaps testing each individual new feature, but not necessarily comprehensively testing obscure combinations.

 

[Tom W]

Pretty serious internal QA failure. Canon has been talking / developing this 1.3 firmware for months, so they hardly rushed it.

I wonder if part of the problem is how they're working with the plandemic - that is, a lot of people are working from home and communication suffers when people can't meet face to face. yeah, I know, they can call one another or use some sort of "FaceTime" program, but it's not the same. No "come over here and look at this" from across the room.

I know it's made some things more difficult for our engineers, though a lot of them also prefer the solitude to allow them to actually work uninterrupted by meetings and such. Kind of a mixed bag.

 

[MadisonMike]

I agree, there is something lost with all the remote work. You never see the facial expressions or body language of people to the discussed "ideas". I see more lost than gained.

 

[cayenne]

I agree, there is something lost with all the remote work. You never see the facial expressions or body language of people to the discussed "ideas". I see more lost than gained.

I guess it depends.

I'm in IT for my "day job"...heavy server, application, coding and database work.

I've been working remote for 8+ years now, with numerous teammates spread all across the US. Most of us have never seen each other face to face ever....and rarely does anyone turn on the camera on Teams meetings.
(no one wants to see you in t-shirt and boxer shorts, or worse).

It's been no problem with massive projects whatsoever....and I mean massive systems moving between cloud and data centers, with 24/7 uptime requirements.

So, it can be done.

Heck, I was pretty busy past 3 years and aside from noticing people wearing masks, I'd not have noticed much was different with the pandemic...


So, it can be done easily. It will be interesting to see if managers can allow it to continue past the pandemic which does seem to be on the downhill side now a bit....because while some people miss the office, there are a LOT out there that like working from home most of the time if not all of the time.

I think it works better with more senior employees....but perhaps it does harm the younger, noobs to the company, where face time and in person politics and personality and making networking connections in those early years ARE important.

Those early years are the building blocks for job hopping and making more money over the coming years...etc.

It will be interesting to see.

C

 

[Jonathan Thill]

Pretty serious internal QA failure. Canon has been talking / developing this 1.3 firmware for months, so they hardly rushed it.

As someone that has been a test Engineer for 25 years I can tell you for sure this escape happened in 1 of 3 ways

1. QA missed it\has no coverage for this use case in their test plans = QA Failure and there are testers writing manual test cases to cover this now.
2. Dev dropped a fix for an unrelated bug late in the release cycle and QA tested this fix and had no reason to think there would be a knock on in the effected code. = QA and Dev failure - QA needs to run a complete release check\sanity on each build. Dev needs to communicate possible regression impact.
3. Rogue check in = Dev Failure - A Dev needs to be put in the box of shame.

1. is the least common source of escapes in mature software as both QA and Dev are aware of the happy path as well as the "What happens if I do this" use cases.
2. is sadly the area we get killed by the most, this is often compounded by management demanding the feature(s) are released faster and are shocked when its DOA...
3. Normally does not happen with the same Dev more then twice and as long as code freeze is being managed correctly will never happen.

The stuff we had to hot fix at EA would blow your mind, I once had to fly from Vancouver to Glasgow to deliver Gold Master builds of FIFA... Good times

Oh and I should add that I have been working from home in my current role for over a 1 year and in a lot of ways it has made us a better team, I still go into the office to deal with hardware from time to time but for the most part where we work does not really matter.

 

[cayenne]

OH heck...I forgot what I originally came to post.

After reading this, I'm wondering if it is time for me to do a firmware update on my early model Canon 5D3?

It has never had a firmware update. I wonder if I"m missing anything there?

cayenne

 

[Jonathan Thill]

(no one wants to see you in t-shirt and boxer shorts, or worse).

Guilty

 

[miketcool]

Yep.

I find that with most things in life....it is best to not test the water with both feet.

I usually let others try things out before I do......

Now if it’s not mission critical to my business, I don’t mind taking the leap. Right now I’m running a dozen beta or pre-release software builds on my Mac Mini M1 instead of waiting for ARM comparability. I have a backup machine and everything lives in the cloud. Sometimes you can benefit if you’re prepared. The EOS R unexpectedly became more useful than my 5Dmk4 when I ordered it from the launch.

 

[EOS 4 Life]

Canon had indicated it wanted to up the cadence of its firmware releases, perhaps even going monthly. Reality is hitting, and this update was supposed to see light a bunch of weeks ago. There were probably worse, more obvious bugs that they fire-drilled on, and this was missed. Fast cadence software development usually means accepting higher risk on testing, knowing you have a follow-on update a few weeks later. The firm I work for is as guilty of this as anyone. This usually - but not always - makes companies a bit more lax in initial testing, perhaps testing each individual new feature, but not necessarily comprehensively testing obscure combinations.

I always lose this fight but I argue that the more frequent the release cycle the better.
I find that the longer the release cycle is the greater the reluctance to leave things out and the more pressure there is to rush things in.
With short release cycles, most things can wait until the next and there is rarely a need to rush anything.
Emergency releases like R6 Firmware 1.3.1 do not follow release cycles and can be pushed anytime.
Everything else can wait until it is good and ready.