ftr, I've sent a message to legal-discuss to inquire about the licensing aspect of the OpenJDK as we've been discussing. I believe anyone can follow the thread by subscribing to the legal-discuss@ ML, or you can wait for updates on this thread as I get them.
On Wed, Mar 21, 2018 at 9:49 AM, Jason Brown <jasedbr...@gmail.com> wrote: > If we went down this path, I can't imagine we would build OpenJDK > ourselves, but probably build a release with jlink or javapackager. I > haven't done homework on that yet, but i *think* it uses a blessed OpenJDK > release for the packaging (or perhaps whatever JDK you happen to be > compiling/building with). Thus as long as we build/release when an openJDK > rev is released, we would hypothetically be ok from a secutiry POV. > > That being said, Micke's points about multiple architectures and other > OSes (Windows for sure, macOS not so sure) are a legit concern as those > would need to be separate packages, with separate CI/testing and so on :( > > I'm not sure betting the farm on linux disto support is the path to > happiness, either. Not everyone uses one of the distros mentioned (RH, > ubuntu), nor does everyone use linux (sure, the vast majority is Linux/x86, > but we do support Windows deployment and macOS development). > > -Jason > > > > On Wed, Mar 21, 2018 at 9:26 AM, Michael Burman <mibur...@redhat.com> > wrote: > >> On 03/21/2018 04:52 PM, Josh McKenzie wrote: >> >> This would certainly mitigate a lot of the core problems with the new >>> release model. Has there been any public statements of plans/intent >>> with regards to distros doing this? >>> >> Since the latest official LTS version is Java 8, that's the only one with >> publicly available information For RHEL, OpenJDK8 will receive updates >> until October 2020. "A major version of OpenJDK is supported for a period >> of six years from the time that it is first introduced in any version of >> RHEL, or until the retirement date of the underlying RHEL platform , >> whichever is earlier." [1] >> >> [1] https://access.redhat.com/articles/1299013 >> >> In terms of the burden of bugfixes and security fixes if we bundled a >>> JRE w/C*, cutting a patch release of C* with a new JRE distribution >>> would be a really low friction process (add to build, check CI, green, >>> done), so I don't think that would be a blocker for the concept. >>> >>> And do we have someone actively monitoring CVEs for this? Would we ship >> a version of OpenJDK which ensures that it works with all the major >> distributions? Would we run tests against all the major distributions for >> each of the OpenJDK version we would ship after each CVE with each >> Cassandra version? Who compiles the OpenJDK distribution we would create >> (which wouldn't be the official one if we need to maintain support for each >> distribution we support) ? What if one build doesn't work for one distro? >> Would we not update that CVE? OpenJDK builds that are in the distros are >> not necessarily the pure ones from the upstream, they might include patches >> that provide better support for the distribution - or even fix bugs that >> are not yet in the upstream version. >> >> I guess we also need the Windows versions, maybe the PowerPC & ARM >> versions also at some point. I'm not sure if we plan to support J9 or other >> JVMs at some point. >> >> We would also need to create CVE reports after each Java CVE for >> Cassandra as well I would assume since it would affect us separately (and >> updating only the Java wouldn't help). >> >> To me this sounds like an understatement of the amount of work that would >> go to this. Not to mention the bad publicity if Java CVEs are not actually >> patched instantly in the Cassandra also (and then each user would have to >> validate that the shipped version actually works with their installation in >> their hardware since they won't get support for it from the vendors as it's >> unofficial package). >> >> - Micke >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org >> For additional commands, e-mail: dev-h...@cassandra.apache.org >> >> >
