How are JUMBO hotfixes triaged across various GAIA code trees (R81, R81.10, R81.20, etc)?

[Garrett_DirSec]

Hello -- this is likely a can of worms, but I'm wondering how bugs identified, fixed, and incorporated into ongoing JUMBO takes are translated to other GAIA code trees (or whatever they are called)?

example:

Customer works with support to identify "defect" with R81 that results in hotfix and appears in JUMBO take.

Does Checkpoint automatically incorporate that "fix" into R81.10 and all future GAIA builds (release and development)?

Alternatively, does someone have to separately deal with same bug in different code (if it exists), fight with support and hotfix procedure?

The big umbrella topic:   how does Checkpoint leverage the cycles of customers spent resolving detects in particular version of GAIA and apply everywhere to minimize scenario where others deal with same issue -- even in other versions of code?

thanks -GA

reference hotfix GA.

[Marcel_Gramalla]

Do you know this sk?: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

If a fix is in a Jumbo for R81 it should automatically be in the next Jumbo for R81.10 or R80.40 (depending on where the Bug was found). Of course you should manually check it in the release notes if you need a specific fix. 

[the_rock]

I would let someone from Israel confirm this 100%.

[Bob_Zimmerman]

Part of this can be answered by looking at the jumbo release notes. Let's consider the recent fix "In Overview, some data about disk space may be missing."

Version	Released	Issue IDs
R81.10 jumbo 30	2022-01-13	PRJ-32980, PMTR-74061
R81 jumbo 56	2022-01-17	PRJ-32979, PMTR-74061
R80.40 jumbo 150	2022-01-19	PRJ-32978, PMTR-74061

From this, you can see the PMTR identifier is stable across versions, and the PRJ identifier is version-specific. From the numbering and the timing, it looks a lot like the issue was originally reported in R80.40, identified forward, fixed in the latest dev branch, then the fix was backported to affected versions.

I don't know if they do this with every fix, but a spot-check suggests it is not a rare pattern.

[the_rock]

That makes total sense, but I would still let someone from R&D confirm.

[MeravAlon]

Hi

If issue found and fixed in version x, it will be merged also to version x+1 in case its relevant to this version. This is in order to keep branches aligned and make sure the upgrade process is smooth.

As mentioned above, it is recommended to review the “Compatibility of Jumbo HFA “ sk. It has all the information needed.

Have a great weekend

Merav

[JozkoMrkvicka]

Hi,

What about version x-1 ? What if bug is also present in version x-1 and this version is still supported ? Lets assume the bug was initially found and fixed in R80.40 (version x). Will be fixed in version x+1 (R81), x+2 (R81.10).

But R80.30 (version x-1) and R80.20 (version x-2) are still fully supported by Check Point till September 2022. Will the fix be included in Jumbo for R80.30 ?

[MatanYanay]

Hi @JozkoMrkvicka 

My name is Matan Yanay. I manage the Post release team in Check Point, under Merav Alon Release Operations group. My team is responsible for all the Jumbo releases.

R80.20 and R80.30 are indeed under support till September, and we keep releasing Jumbos for those versions with important fixes.

If a bug was found in version x, it will be backported to version x-1 based on RND decision and its relevancy to this version  – How common it is, how critical the fix is, what is the impact and more.

We highly recommend for customers using R80.20/R80.30 to start planning their upgrade to more updated version to get the best security and quality. Check Point widely recommended version for all deployments is R81.10 with its latest GA Jumbo.

[the_rock]

@MatanYanay ...I just wanted to share feedback I always used to get from customers about jumbo/custom hotfixes. So, say you have scenario like this and again, apologies it its not 100% related to this post...lets say client is using R80.40 version and jumbo take 120 and they have a problem that requires TAC to have R&D send custom fix to fix specific issue they have. Ok, thats great, but then people always come into situation where say if they wish to install higher jumbo take number or go to next major version, that custom fix is literally never included, so then it takes time to create compatible custom fix for new version.

Anyway, to make log story short, it would be nice if those custom fixes would be included in next releases...unless there is a specific reason why they are not.

[PhoneBoy]

There are specific guidelines for including fixes in the jumbo, which many custom fixes do not meet.
We also have customer releases that are often based on a specific version/JHF take.
Anything included in the jumbo must have wide applicability and not require significant code changes (something customer releases often require).

[the_rock]

Thats fair, thank you!

[JozkoMrkvicka]

Or lets say it other way around ... if a bug was found in R80.40 Take 120, BUT is NOT present in R81 or R81.10 (with latest Jumbo).

Check Point will advise that the Customer should upgrade to R8x to fix the issue. Is the Customer willing to upgrade just to get rid of that particular bug? Or will accept to have custom private hotfix for specific version of Jumbo ? Maybe that bug is not considered by R&D to be included in Jumbo train of R80.40.

[the_rock]

It all really depends on a customer...like with any vendor, people may upgrade to newer version and that would fix existing problem, but may introduce bunch of new issues. Its always sort of "catch 22" as they say : - )

[Dorit_Dor]

The main purpose of customer release is to bridge the time till that capability is supported in main train recommended version. Its the interest of both sides to move out of customer release as the complexity and the supportability is much more problematic. 
There will often be negotiation with the customer on how fast they can move out of the customer release once its formally inside wide/recommended version. Until that point (that we move the customer), we will slide/fix one-off fixes to that specific side branch but its unlikely to get into the jumbo. 

There is no point to fix the specific bug in jumbo of the old version without including all the customer release in that jumbo… remember that at the same time we have 10k’s of customers that use these jumbo and expect perfect jumbo (no degradations).
So if this complex code, and major change was done in next version to support it, we should help the customers move to new version and not expect it on the old version inside jumbo - you cant hold two sides of the rope

Dorit 

[the_rock]

Thank you @Dorit_Dor ...I agree with your statement, also what @PhoneBoy and @JozkoMrkvicka said as well. I just believe its more convenience factor to most customers that end up getting these custom fixes, but I totally get the logic in your response.