Hi Johan, Thanks for explaining. I've taken a look at that JEP 14 document, and I can certainly understand the reasoning behind it.
And indeed, this is a P4 bug, not particularly critical. Though the fix is small and low-risk, it is still a change and it inevitably takes resources to backport (always more than expected, I know :-)). Depending on how strict the "backport as little as possible" rule is interpreted, this may or may not be taken along. I don't have anything particular to throw into the balance, so I'll just see where this goes. In any case, thanks for considering / discussing it, and for having taken the time for your thoughful response. -- Johan C On Tue, Nov 5, 2024 at 11:59 AM Johan Vos <jo...@lodgon.com> wrote: > > Hi Johan, > > Sorry for not replying earlier. > Since this is a real small fix, I think it makes sense to backport it to > 17/21. > I'm a bit hesitant because of JEP 14 [1] and the current discussions on the > Tip&Tail approach [2] , where it is explicitly discouraged to backport > anything apart from vulnerabilities and critical errors. Since this is a P4 > bug, I don't think it qualifies -- hence my doubt. > > This is a situation that I believe could be discussed in jdk-dev -- not for > this issue in particular, but rather the principle: what is the > recommendation with backport requests for P4 bugs that are "small" and > "guaranteed to have no regression"? > > I don't think it's good to have the discussion at 2 places, but to summarize > some of the key reasons on why not backporting non-criticial things: > * we do not want to break existing work in LTS releases (software that relies > on some undocumented internal JavaFX behavior might go wrong if the behavior > is changed) > * we need to make sure the CPU fixes can "easily" be backported. > * time spent in tail-backporting can not be spent in tip-development. And > unfortunately, I learned the hard way that backporting is much more > time-consuming (and error-prone) than I hoped for. > > Having said that, I definitely don't want to reject this upfront -- just want > to clarify the complexity and I very much welcome other input. > > - Johan > > [1] https://openjdk.org/jeps/14 > [2] https://mail.openjdk.org/pipermail/jdk-dev/2024-October/009433.html > > > Op di 5 nov 2024 om 11:40 schreef Johan Corveleyn <jcor...@gmail.com>: >> >> On Mon, Oct 7, 2024 at 5:01 PM Johan Corveleyn <jcor...@gmail.com> wrote: >> > >> > On Tue, Oct 1, 2024 at 10:30 PM Johan Corveleyn <jcor...@gmail.com> wrote: >> > > >> > > On Mon, Sep 30, 2024 at 5:23 PM Kevin Rushforth >> > > <kevin.rushfo...@oracle.com> wrote: >> > > > >> > > > Gluon maintains JavaFX 17 and 21, so Johan can answer that. >> > > > >> > > > There is no maintainer for the JavaFX 8 or 11 code lines in OpenJDK. >> > > >> > > Ah yes, for 8 we use the Oracle JDK which includes its JavaFX build. >> > > So for backport to Oracle Java 8 I guess we'd need to ask Oracle. >> > > >> > > Having this fix backported into OpenJFX 17 and 21 would be great though. >> > >> > Coming back to this: any chance this fix could be backported to >> > OpenJFX 17 and 21? >> >> One last try: anyone able to backport this deadkey fix to 17 and 21? >> Or even take it into consideration for inclusion in OpenJFX 11 or JDK >> 8? >> >> -- >> Johan
