Workshop proposal: How to do backports/bug fixes properly?

Severin Gehwolf sgehwolf at redhat.com
Fri Jan 18 10:13:50 UTC 2019


With the new fast-release cycle it's hard to know where fixes should
get pushed in certain phases of the development cycle. Let's exclude
enhancements for this discussion for simplicity.

Consider the fast-release-cadence cycle:

---------------------------------------------------------------------------------------
                             ,- JDK 12,     ,- JDK 12,     ,-- JDK 12 GA
Time:                        |  RDP 1       | RDP 2        |
                            \|/            \|/            \|/
                             `              `              `
---------------------------------------------------------------------------------------


                ,--jdk-updates/jdk11u----                   ,--------jdk-updates/jdk12u
 ,---jdk/jdk11-+              ,------------jdk/jdk12-------+ 
+----------------------------+-----------------------jdk/jdk---------------------------


We are currently between JDK 12, RDP 1 and JDK 12, RDP 2. So if a
bugfix is being developed it's not entirely clear where to push the fix
to. Should it go to jdk/jdk, or jdk/jdk12? Do all bugfixes go to
jdk/jdk12 directly before RDP 2? Would I need to push it to both,
jdk/jdk and jdk/jdk12?

What if the fix needs to go to JDK 11 too? It's possible for a fix to
be in jdk/jdk and jdk-updates/jdk11u, but not in jdk/jdk12 because of
some RDP 2 rules where only high priority bugs can be fixed. This might
cause issues where JDK 12 could potentially regress if the developer
forgets to revisit the backport for jdk-updates/jdk12u once that tree
exists.

Who gets to decide which fix gets pushed where?

If a backport depends on other fixes getting backported too, what's the
process to get it included? Should the backport merged changes? Keep
them separate as much as possible? Where do we draw the line?

Perhaps we could discuss those issues and set some ground rules. Trying
to simplify the process would help too.

Thanks,
Severin



More information about the workshop-discuss mailing list