Re: OpenJDK SRU exception

2018-09-10 Thread Tiago Daitx
There has been a few changes to the package list.

New packages to include:
eclipse-debian-helper
eclipse-platform-resources
eclipse-platform-runtime
eclipse-platform-text
eclipse-platform-ui
equinox-bundles
equinox-framework
hibiscus
jaxrpc-api
jsonb-api
jws-api
libcommons-jexl3-java
libmbassador-java
mariadb-connector-java
mckoisqldb
metro-policy
netty-reactive-streams
saaj-ri

Regards,
Tiago
On Thu, Aug 2, 2018 at 5:54 AM Tiago Daitx  wrote:
>
> OpenJDK-11 has been made the default-jdk in Bionic [1] a few months
> back. The source package was named openjdk-lts and the binaries are
> named openjdk-11-*, although we are still using openjdk-10 as the
> source. We will move to openjdk-11 after it reaches GA.
>
> Meanwhile we would also like to ask for a blanket SRU exception for
> java related packages for purposes of fixing and improving openjdk-11
> compatibility. Those packages might need additional backports in order
> to fix FTBFS and runtime errors when moving to the newer OpenJDK.
>
> The list of packages - 1005 in total as of now - is the same as the
> ones maintained by the pkg-java group in Debian [2] and can be seen by
> the end of this email. For reference please see the list of packages
> for which we requested a FFe before the Bionic release [3].
>
>
> References:
> [1] https://launchpad.net/ubuntu/+source/java-common/0.62ubuntu2
> [2] 
> https://qa.debian.org/developer.php?login=pkg-java-maintainers%40lists.alioth.debian.org&set=yes&comaint=yes&version=experimental
> [3] https://launchpad.net/bugs/1760920
>
> Packages for which we are requesting the SRU exception:
> abego-treelayout
> access-modifier-checker
> activemq
> activemq-activeio
> activemq-protobuf
> aether
> aether-ant-tasks
> afterburner.fx
> airlift-airline
> airlift-slice
> akuma
> androidsdk-tools
> angular-maven-plugin
> animal-sniffer
> annotation-indexer
> ant
> ant-contrib
> antelope
> antlr-maven-plugin
> antlr3
> antlr3.2
> antlr4
> apache-curator
> apache-directory-api
> apache-directory-jdbm
> apache-directory-server
> apache-log4j-extras1.2
> apache-log4j1.2
> apache-log4j2
> apache-mime4j
> apache-pom
> argparse4j
> args4j
> asm
> asm3
> aspectj
> aspectj-maven-plugin
> assertj-core
> async-http-client
> at-at-clojure
> atinject-jsr330
> autocomplete
> automaton
> avalon-framework
> avro-java
> axis
> axmlrpc
> barclay
> batik
> bcel
> beansbinding
> beckon-clojure
> bidi-clojure
> bindex
> bintray-client-java
> bnd
> boilerpipe
> bookkeeper
> bouncycastle
> bridge-method-injector
> bsaf
> bsh
> build-helper-maven-plugin
> byte-buddy
> bytecode
> c3p0
> ca-certificates-java
> carrotsearch-hppc
> carrotsearch-randomizedtesting
> castor
> cdi-api
> cdk
> cglib
> checkstyle
> cheshire-clojure
> classycle
> clirr
> clj-digest-clojure
> clj-http-clojure
> clj-time-clojure
> clj-tuple-clojure
> clj-yaml-clojure
> clojure
> clojure-maven-plugin
> closure-compiler
> clout-clojure
> cmdreader
> cobertura
> codenarc
> cofoja
> colorpicker
> comidi-clojure
> commons-beanutils
> commons-configuration
> commons-configuration2
> commons-csv
> commons-daemon
> commons-exec
> commons-httpclient
> commons-io
> commons-jci
> commons-jcs
> commons-math
> commons-math3
> commons-parent
> commons-pool
> commons-pool2
> commons-vfs
> compojure-clojure
> compress-lzf
> conversant-disruptor
> core-match-clojure
> core-memoize-clojure
> cortado
> cpath-clojure
> cpptasks
> cronometer
> crypto-equality-clojure
> crypto-random-clojure
> css2xslfo
> csvjdbc
> cup
> curvesapi
> data-priority-map-clojure
> dbus-java
> dd-plist
> derby
> dirgra
> disruptor
> dnsjava
> dnssecjava
> dokujclient
> dom4j
> doxia
> doxia-sitetools
> dropwizard-metrics
> dtd-parser
> dujour-version-check-clojure
> dumbster
> dynalang
> easybind
> easyconf
> easymock
> ecj
> eclipse
> eclipse-anyedit
> eclipse-cdt
> eclipse-cdt-pkg-config
> eclipse-eclox
> eclipse-egit
> eclipse-emf
> eclipse-gef
> eclipse-linuxtools
> eclipse-mercurialeclipse
> eclipse-mylyn
> eclipse-mylyn-tasks-github
> eclipse-ptp
> eclipse-pydev
> eclipse-remote-services-api
> eclipse-rse
> eclipse-subclipse
> eclipse-wtp
> eclipse-xsd
> eclipselink
> eclipselink-jpa-2.1-spec
> ehcache
> eigenbase-resgen
> electric
> entagged
> excalibur-logger
> excalibur-logkit
> exec-maven-plugin
> f2j
> fast-zip-clojure
> fastinfoset
> felix-bundlerepository
> felix-framework
> felix-gogo-command
> felix-gogo-runtime
> felix-gogo-shell
> felix-main
> felix-osgi-obr
> felix-resolver
> felix-shell
> felix-shell-tui
> felix-utils
> fest-assert
> fest-reflect
> fest-test
> fest-util
> findbugs
> flute
> fontawesomefx
> fontchooser
> fop
> freehep-chartableconverter-plugin
> freehep-export
> freehep-graphics2d
> freehep-graphicsio
> freehep-graphicsio-emf
> freehep-graphicsio-java
> freehep-graphicsio-pdf
> freehep-graphicsio-ps
> freehep-graphicsio-svg
> freehep-graphicsio-swf
> freehep-graphicsio-tests
> freehep-io
> freehep-swing
> freehep-util
> freehep-xml
> freeplane
> gant
> ganymed-ssh2
> gatk-native-bindings

Re: OpenJDK SRU exception

2018-08-01 Thread Tiago Daitx
OpenJDK-11 has been made the default-jdk in Bionic [1] a few months
back. The source package was named openjdk-lts and the binaries are
named openjdk-11-*, although we are still using openjdk-10 as the
source. We will move to openjdk-11 after it reaches GA.

Meanwhile we would also like to ask for a blanket SRU exception for
java related packages for purposes of fixing and improving openjdk-11
compatibility. Those packages might need additional backports in order
to fix FTBFS and runtime errors when moving to the newer OpenJDK.

The list of packages - 1005 in total as of now - is the same as the
ones maintained by the pkg-java group in Debian [2] and can be seen by
the end of this email. For reference please see the list of packages
for which we requested a FFe before the Bionic release [3].


References:
[1] https://launchpad.net/ubuntu/+source/java-common/0.62ubuntu2
[2] 
https://qa.debian.org/developer.php?login=pkg-java-maintainers%40lists.alioth.debian.org&set=yes&comaint=yes&version=experimental
[3] https://launchpad.net/bugs/1760920

Packages for which we are requesting the SRU exception:
abego-treelayout
access-modifier-checker
activemq
activemq-activeio
activemq-protobuf
aether
aether-ant-tasks
afterburner.fx
airlift-airline
airlift-slice
akuma
androidsdk-tools
angular-maven-plugin
animal-sniffer
annotation-indexer
ant
ant-contrib
antelope
antlr-maven-plugin
antlr3
antlr3.2
antlr4
apache-curator
apache-directory-api
apache-directory-jdbm
apache-directory-server
apache-log4j-extras1.2
apache-log4j1.2
apache-log4j2
apache-mime4j
apache-pom
argparse4j
args4j
asm
asm3
aspectj
aspectj-maven-plugin
assertj-core
async-http-client
at-at-clojure
atinject-jsr330
autocomplete
automaton
avalon-framework
avro-java
axis
axmlrpc
barclay
batik
bcel
beansbinding
beckon-clojure
bidi-clojure
bindex
bintray-client-java
bnd
boilerpipe
bookkeeper
bouncycastle
bridge-method-injector
bsaf
bsh
build-helper-maven-plugin
byte-buddy
bytecode
c3p0
ca-certificates-java
carrotsearch-hppc
carrotsearch-randomizedtesting
castor
cdi-api
cdk
cglib
checkstyle
cheshire-clojure
classycle
clirr
clj-digest-clojure
clj-http-clojure
clj-time-clojure
clj-tuple-clojure
clj-yaml-clojure
clojure
clojure-maven-plugin
closure-compiler
clout-clojure
cmdreader
cobertura
codenarc
cofoja
colorpicker
comidi-clojure
commons-beanutils
commons-configuration
commons-configuration2
commons-csv
commons-daemon
commons-exec
commons-httpclient
commons-io
commons-jci
commons-jcs
commons-math
commons-math3
commons-parent
commons-pool
commons-pool2
commons-vfs
compojure-clojure
compress-lzf
conversant-disruptor
core-match-clojure
core-memoize-clojure
cortado
cpath-clojure
cpptasks
cronometer
crypto-equality-clojure
crypto-random-clojure
css2xslfo
csvjdbc
cup
curvesapi
data-priority-map-clojure
dbus-java
dd-plist
derby
dirgra
disruptor
dnsjava
dnssecjava
dokujclient
dom4j
doxia
doxia-sitetools
dropwizard-metrics
dtd-parser
dujour-version-check-clojure
dumbster
dynalang
easybind
easyconf
easymock
ecj
eclipse
eclipse-anyedit
eclipse-cdt
eclipse-cdt-pkg-config
eclipse-eclox
eclipse-egit
eclipse-emf
eclipse-gef
eclipse-linuxtools
eclipse-mercurialeclipse
eclipse-mylyn
eclipse-mylyn-tasks-github
eclipse-ptp
eclipse-pydev
eclipse-remote-services-api
eclipse-rse
eclipse-subclipse
eclipse-wtp
eclipse-xsd
eclipselink
eclipselink-jpa-2.1-spec
ehcache
eigenbase-resgen
electric
entagged
excalibur-logger
excalibur-logkit
exec-maven-plugin
f2j
fast-zip-clojure
fastinfoset
felix-bundlerepository
felix-framework
felix-gogo-command
felix-gogo-runtime
felix-gogo-shell
felix-main
felix-osgi-obr
felix-resolver
felix-shell
felix-shell-tui
felix-utils
fest-assert
fest-reflect
fest-test
fest-util
findbugs
flute
fontawesomefx
fontchooser
fop
freehep-chartableconverter-plugin
freehep-export
freehep-graphics2d
freehep-graphicsio
freehep-graphicsio-emf
freehep-graphicsio-java
freehep-graphicsio-pdf
freehep-graphicsio-ps
freehep-graphicsio-svg
freehep-graphicsio-swf
freehep-graphicsio-tests
freehep-io
freehep-swing
freehep-util
freehep-xml
freeplane
gant
ganymed-ssh2
gatk-native-bindings
gentlyweb-utils
geogebra
geronimo-annotation-1.3-spec
geronimo-commonj-spec
geronimo-concurrent-1.0-spec
geronimo-ejb-3.2-spec
geronimo-interceptor-3.0-spec
geronimo-j2ee-management-1.1-spec
geronimo-jacc-1.1-spec
geronimo-jcache-1.0-spec
geronimo-jpa-2.0-spec
geronimo-jta-1.1-spec
geronimo-jta-1.2-spec
geronimo-osgi-support
geronimo-validation-1.0-spec
geronimo-validation-1.1-spec
gettext-ant-tasks
gettext-maven-plugin
gkl
glassfish
gluegen2
gmavenplus
gmbal
gmbal-commons
gmbal-pfl
gmetric4j
gmetrics
gnome-split
gossip
gradle
gradle-debian-helper
gradle-jflex-plugin
gradle-plugin-protobuf
gradle-propdeps-plugin
graxxia
groovy
groovycsv
gs-collections
guava-libraries
guice
h2database
hawtbuf
hawtdispatch
hawtjni
hbci4java
hdrhistogram
headius-options
hessian
hiccup-clojure
hikaricp
honeysql-clojure
hsqldb
htrace
httpcomponents-asyncclient
httpcomponents-client
httpcomponents-core
httpunit
icu4j
icu4j-4.2
ic

Re: OpenJDK SRU exception

2018-03-23 Thread Steve Langasek
On Fri, Mar 23, 2018 at 09:43:40PM -0700, Steve Langasek wrote:
> On Fri, Feb 2, 2018 at 11:58 AM, Tiago Daitx  
> wrote:
> > On behalf of the Ubuntu Foundations Team, I am requesting an SRU
> > exception for OpenJDK. Our plan is to release OpenJDK 10 as the
> > default JRE/JDK [1] for Bionic, and then move the default JRE/JDK in
> > main to OpenJDK 11 in September/October 2018 as an SRU.

> > = Proposed Plan =
> > Bionic will be released with OpenJDK 10 as the default JRE/JDK and
> > OpenJDK 11 will replace it once it reaches GA.

> > OpenJDK 8 will be moved to universe and remain available there for
> > 18.04, to provide migration time for packages that can't be build with
> > OpenJDK 10 or 11.

> > OpenJDK 8 will remain in main in 16.04 LTS (which reaches EOL in April 
> > 2021).

> Not mentioned in this description is that we should migrate ASAP to OpenJDK9
> by default, to ease the transition to OpenJDK10 between now and release.

> (Not mentioned because at the time you first wrote, this wasn't expected to
> miss feature freeze.)

> > If we are going to switch to OpenJDK 11 in bionic once released, we
> > want to avoid OpenJDK 8 as the default JRE/JDK in Bionic at release
> > time because any additional interface delta that exists between 8 and
> > 11 not only exposes the archive to breakage, it also exposes external
> > consumers of the JDK to breakage.  In comparison, the interface delta
> > between OpenJDK 10 and OpenJDK 11 is expected to be fairly small,
> > especially in comparison with the delta between OpenJDK 8 and OpenJDK
> > 9 that we already know is large.  We should therefore release with
> > OpenJDK 10 as the default JDK in 18.04, transitioning to OpenJDK 11
> > when it is released.

> I agree with this rationale and approve this SRU exception for OpenJDK 11 in
> Ubuntu 18.04 LTS.

One further outstanding question is how to name these packages in order to
avoid leaving binary packages in main at release time with no security
support and no automated upgrade path.

My suggestion is to use the same source and binary package names for both
openjdk-10 (at release time) and openjdk-11 (once SRUed) in bionic, so that
the upgrade just happens normally as part of security updates and there are
no concerns of users who upgraded to 18.04 early being islanded on a
no-longer-supported openjdk-10 package.

One way to do this would be to simply name the openjdk-10 package
"openjdk-11", with a 10.x version number.  This would signal to users that
openjdk-11 is coming, making it less of a surprise.

You could also call it openjdk-10, but it's less obvious to have an
openjdk-10 version 11, IMHO.

You could even do something like "openjdk-lts", but that also has downsides
of confusion with the upstream meaning of LTS.


Alternative approaches, which have been considered but that I think are
worse than the above:

 - Keep openjdk-10 only in the -proposed pocket until after release, then
   publish it to -updates.  This would mean that either there is no openjdk
   in the release pocket at bionic release, so 18.04 is not self-buildable;
   or there would be some other version of openjdk left in the release which
   is *also* going to go EOL, and is therefore also going to mislead users.

 - Publish openjdk-10 in main in the bionic release pocket, but use metadata
   in the archive to mark it only supported in September.  This doesn't help
   the majority of users who never run ubuntu-supported-status or look at
   the field in their Packages files.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature
-- 
Ubuntu-release mailing list
Ubuntu-release@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-release


Re: OpenJDK SRU exception

2018-03-23 Thread Steve Langasek
Hi Tiago,

Thanks for this additional analysis.  This is useful to understand in light
of the concerns (which we discussed off list) that future releases of
OpenJDK between 9 and 11 may not be fully binary compatible after all with
binaries built against OpenJDK8, and may therefore not be a viable fallback
for packages which fail to build with OpenJDK 10 or 11.

It would be ideal to fix as many of these build failures as possible before
18.04 releases.  The number of these currently failing packages looks
manageable, especially considering the good news that maven-related fixes
are currently in progress in Debian.

I do not consider these build failures a blocker for the plan to switch to
OpenJDK10 by default in 18.04.

To make sure I understand the whole plan: will the maven stack need to be
rebuilt in 18.04 against OpenJDK9 to ensure packages do not fail to build in
SRU?  Or were these rebuilds only for testing?

On Fri, Mar 23, 2018 at 11:34:49PM +0100, Tiago Daitx wrote:
> On behalf of the Ubuntu Foundations Team, I would like to provide
> further information on the outstanding issues of the OpenJDK 9
> transition.

> Of the 35 direct reverse build and runtime dependencies of java-common
> in Bionic/main, which amount to 26 source packages, there are 5 that
> currently FTBFS when build with openjdk-9:

[...]

> The 2 important runtimes in Bionic/main are tomcat8 and libreoffice
> (the database component) and both are run fine under OpenJDK 9. Let me
> know if there is any particular use cases to try on those.

> There are 171 packages - amounting to 97 source packages - that are a
> direct reverse build or runtime dependency of maven in Bionic. Of
> those there are 13 failures:

[...]

> Other outstanding packages that FTBFS with OpenJDK 9:
> - bnd* (33)
> - gradle* (16)

I recognize gradle; I was unfamiliar with bnd.  What is interesting about
these two packages in particular?

It would be interesting to know about other java FTBFS in universe. 
However, we can gather information about this after java-common has been
updated, as part of the next full-archive test rebuild of bionic.

To the main body of the plan:

On Fri, Feb 2, 2018 at 11:58 AM, Tiago Daitx  wrote:
> On behalf of the Ubuntu Foundations Team, I am requesting an SRU
> exception for OpenJDK. Our plan is to release OpenJDK 10 as the
> default JRE/JDK [1] for Bionic, and then move the default JRE/JDK in
> main to OpenJDK 11 in September/October 2018 as an SRU.

> = Proposed Plan =
> Bionic will be released with OpenJDK 10 as the default JRE/JDK and
> OpenJDK 11 will replace it once it reaches GA.

> OpenJDK 8 will be moved to universe and remain available there for
> 18.04, to provide migration time for packages that can't be build with
> OpenJDK 10 or 11.

> OpenJDK 8 will remain in main in 16.04 LTS (which reaches EOL in April 2021).

Not mentioned in this description is that we should migrate ASAP to OpenJDK9
by default, to ease the transition to OpenJDK10 between now and release.

(Not mentioned because at the time you first wrote, this wasn't expected to
miss feature freeze.)

> = Rationale =
> Oracle will end upstream security support for OpenJDK 8 in September
> 2018 [2].  Red Hat has indicated that they will provide support until
> October 2020 [3,4].  Canonical is committed to working with fellow
> distributors of OpenJDK 8 to provide security support through the end
> of Ubuntu 16.04 LTS’s supported lifecycle in April 2021, but would
> prefer not to extend its maintenance costs a further two years beyond
> this by including OpenJDK 8 in main in Bionic.

> Meanwhile, the OpenJDK project has moved to a 6-month release cycle
> with an LTS version every 3 years [2].

> The first LTS version is OpenJDK 11, to be released on September 2018
> and supported by Oracle until September 2021. Since it is an LTS
> release, we expect the OpenJDK community will align around this
> version to extend support beyond the end of Oracle’s security support
> period.

> If we are going to switch to OpenJDK 11 in bionic once released, we
> want to avoid OpenJDK 8 as the default JRE/JDK in Bionic at release
> time because any additional interface delta that exists between 8 and
> 11 not only exposes the archive to breakage, it also exposes external
> consumers of the JDK to breakage.  In comparison, the interface delta
> between OpenJDK 10 and OpenJDK 11 is expected to be fairly small,
> especially in comparison with the delta between OpenJDK 8 and OpenJDK
> 9 that we already know is large.  We should therefore release with
> OpenJDK 10 as the default JDK in 18.04, transitioning to OpenJDK 11
> when it is released.

I agree with this rationale and approve this SRU exception for OpenJDK 11 in
Ubuntu 18.04 LTS.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.co

Re: OpenJDK SRU exception

2018-03-23 Thread Tiago Daitx
On behalf of the Ubuntu Foundations Team, I would like to provide
further information on the outstanding issues of the OpenJDK 9
transition.

Of the 35 direct reverse build and runtime dependencies of java-common
in Bionic/main, which amount to 26 source packages, there are 5 that
currently FTBFS when build with openjdk-9:
- gettext* (1001)
- db5.3 (130)
- apport* (28)
- brltty* (18)
- sonic* (6)

The number represents how many direct reverse build and runtime
dependencies each package has. An asterisk represents that there is a
known working patch.

Also gettext’s Debian bug #892733 might also require a fix as msgfmt
causes further packages to FTBFS.

The 2 important runtimes in Bionic/main are tomcat8 and libreoffice
(the database component) and both are run fine under OpenJDK 9. Let me
know if there is any particular use cases to try on those.

There are 171 packages - amounting to 97 source packages - that are a
direct reverse build or runtime dependency of maven in Bionic. Of
those there are 13 failures:
- maven-debian-helper (504)
- maven-bundle-plugin* (178)
- antlr3* (29)
- maven-enforcer (17)
- libxbean-java (13)
- istack-commons (4)
- apache-directory-server (3)
- polyglot-maven (2)
- mustache-java (2)
- maven-processor-plugin (2)
- ruby-license-finder (0)
- elki (0)
- bridge-method-injector (0)

The maven-bundle-plugin is under work in Debian, a fix is expected
today and will enable further testing of its dependencies.

Other outstanding packages that FTBFS with OpenJDK 9:
- bnd* (33)
- gradle* (16)

Regards,
Tiago

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892733

On Fri, Feb 2, 2018 at 11:58 AM, Tiago Daitx  wrote:
> On behalf of the Ubuntu Foundations Team, I am requesting an SRU
> exception for OpenJDK. Our plan is to release OpenJDK 10 as the
> default JRE/JDK [1] for Bionic, and then move the default JRE/JDK in
> main to OpenJDK 11 in September/October 2018 as an SRU.
>
> = Proposed Plan =
> Bionic will be released with OpenJDK 10 as the default JRE/JDK and
> OpenJDK 11 will replace it once it reaches GA.
>
> OpenJDK 8 will be moved to universe and remain available there for
> 18.04, to provide migration time for packages that can't be build with
> OpenJDK 10 or 11.
>
> OpenJDK 8 will remain in main in 16.04 LTS (which reaches EOL in April 2021).
>
> = Rationale =
> Oracle will end upstream security support for OpenJDK 8 in September
> 2018 [2].  Red Hat has indicated that they will provide support until
> October 2020 [3,4].  Canonical is committed to working with fellow
> distributors of OpenJDK 8 to provide security support through the end
> of Ubuntu 16.04 LTS’s supported lifecycle in April 2021, but would
> prefer not to extend its maintenance costs a further two years beyond
> this by including OpenJDK 8 in main in Bionic.
>
> Meanwhile, the OpenJDK project has moved to a 6-month release cycle
> with an LTS version every 3 years [2].
>
> The first LTS version is OpenJDK 11, to be released on September 2018
> and supported by Oracle until September 2021. Since it is an LTS
> release, we expect the OpenJDK community will align around this
> version to extend support beyond the end of Oracle’s security support
> period.
>
>
> If we are going to switch to OpenJDK 11 in bionic once released, we
> want to avoid OpenJDK 8 as the default JRE/JDK in Bionic at release
> time because any additional interface delta that exists between 8 and
> 11 not only exposes the archive to breakage, it also exposes external
> consumers of the JDK to breakage.  In comparison, the interface delta
> between OpenJDK 10 and OpenJDK 11 is expected to be fairly small,
> especially in comparison with the delta between OpenJDK 8 and OpenJDK
> 9 that we already know is large.  We should therefore release with
> OpenJDK 10 as the default JDK in 18.04, transitioning to OpenJDK 11
> when it is released.
>
> = Technical details =
>
> There are 24 packages in bionic/main with a build dependency on
> OpenJDK 8 (the current default-jdk). Of these there are 8 FTBFS with
> default-jdk set to openjdk-9 and 10 FTBFS with default-jdk set to
> openjdk-10. These will be fixed before Bionic’s release.
>
> = Affected packages in main =
> $ sort -u \
> <(reverse-depends -b -r bionic -c main -l default-jdk) \
> <(reverse-depends -b -r bionic -c main -l default-jdk-headless)
> apport
> automake-1.15
> awstats
> brltty
> ca-certificates-java
> ceph
> commons-pool
> db5.3
> erlang
> gettext
> hsqldb1.8.0
> java-atk-wrapper
> libcommons-collections3-java
> libcommons-dbcp-java
> liblouisutdml
> libphonenumber
> libreoffice
> libreoffice-l10n
> lintian
> protobuf
> sonic
> taglibs-standard
> tomcat8
> xapian-bindings
>
>
> = Other =
> I made a timeline to visualize the release and EOL dates of OpenJDK
> and Ubuntu [5].
>
> Debian is also affected by the new OpenJDK release cycle [6].
>
> Regards,
> Tiago
>
>
> [1] Default JRE/JDK as in packages default-jre and default-jdk (as
> well as the associated -headless packages)
> [2] ht

OpenJDK SRU exception

2018-02-02 Thread Tiago Daitx
On behalf of the Ubuntu Foundations Team, I am requesting an SRU
exception for OpenJDK. Our plan is to release OpenJDK 10 as the
default JRE/JDK [1] for Bionic, and then move the default JRE/JDK in
main to OpenJDK 11 in September/October 2018 as an SRU.

= Proposed Plan =
Bionic will be released with OpenJDK 10 as the default JRE/JDK and
OpenJDK 11 will replace it once it reaches GA.

OpenJDK 8 will be moved to universe and remain available there for
18.04, to provide migration time for packages that can't be build with
OpenJDK 10 or 11.

OpenJDK 8 will remain in main in 16.04 LTS (which reaches EOL in April 2021).

= Rationale =
Oracle will end upstream security support for OpenJDK 8 in September
2018 [2].  Red Hat has indicated that they will provide support until
October 2020 [3,4].  Canonical is committed to working with fellow
distributors of OpenJDK 8 to provide security support through the end
of Ubuntu 16.04 LTS’s supported lifecycle in April 2021, but would
prefer not to extend its maintenance costs a further two years beyond
this by including OpenJDK 8 in main in Bionic.

Meanwhile, the OpenJDK project has moved to a 6-month release cycle
with an LTS version every 3 years [2].

The first LTS version is OpenJDK 11, to be released on September 2018
and supported by Oracle until September 2021. Since it is an LTS
release, we expect the OpenJDK community will align around this
version to extend support beyond the end of Oracle’s security support
period.


If we are going to switch to OpenJDK 11 in bionic once released, we
want to avoid OpenJDK 8 as the default JRE/JDK in Bionic at release
time because any additional interface delta that exists between 8 and
11 not only exposes the archive to breakage, it also exposes external
consumers of the JDK to breakage.  In comparison, the interface delta
between OpenJDK 10 and OpenJDK 11 is expected to be fairly small,
especially in comparison with the delta between OpenJDK 8 and OpenJDK
9 that we already know is large.  We should therefore release with
OpenJDK 10 as the default JDK in 18.04, transitioning to OpenJDK 11
when it is released.

= Technical details =

There are 24 packages in bionic/main with a build dependency on
OpenJDK 8 (the current default-jdk). Of these there are 8 FTBFS with
default-jdk set to openjdk-9 and 10 FTBFS with default-jdk set to
openjdk-10. These will be fixed before Bionic’s release.

= Affected packages in main =
$ sort -u \
<(reverse-depends -b -r bionic -c main -l default-jdk) \
<(reverse-depends -b -r bionic -c main -l default-jdk-headless)
apport
automake-1.15
awstats
brltty
ca-certificates-java
ceph
commons-pool
db5.3
erlang
gettext
hsqldb1.8.0
java-atk-wrapper
libcommons-collections3-java
libcommons-dbcp-java
liblouisutdml
libphonenumber
libreoffice
libreoffice-l10n
lintian
protobuf
sonic
taglibs-standard
tomcat8
xapian-bindings


= Other =
I made a timeline to visualize the release and EOL dates of OpenJDK
and Ubuntu [5].

Debian is also affected by the new OpenJDK release cycle [6].

Regards,
Tiago


[1] Default JRE/JDK as in packages default-jre and default-jdk (as
well as the associated -headless packages)
[2] http://www.oracle.com/technetwork/java/eol-135779.html
Note: do not confuse the Oracle proprietary JDK support dates with the
OpenJDK support they provide, the proprietary support runs longer by a
couple/few years.
[3] http://mail.openjdk.java.net/pipermail/jdk-dev/2017-November/000175.html
[4] https://access.redhat.com/articles/1299013
[5] https://time.graphics/line/39488
[6] https://lists.debian.org/debian-java/2017/11/msg00028.html


-- 
Tiago Stürmer Daitx
Software Engineer
tiago.da...@canonical.com

PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com)
Fingerprint = 45D0 FE5A 8109 1E91 866E  8CA4 1931 8D5E F5B2 13BE

-- 
Ubuntu-release mailing list
Ubuntu-release@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-release