Hi Thorsten, I just wanted to respond with a thank you for the explanation! I'm going to sit down with some coffee and map this out and see if/how OpenJDK can provide backport sets.
I'll respond here after I have a chat to Matthias next Monday. Cheers, Martijn On Mon, 27 May 2019 at 17:21, Thorsten Glaser <t.gla...@tarent.de> wrote: > Hi Martijn, > > > understanding of how OpenJDK source(s) map onto the Debian packaging > > system/channels. It's been a failing on the OpenJDK community side to > help > > the Debian side of this, as relates to the releases, is this: > > > Debian 9 (stretch), the current stable release, shipped with > OpenJDK 8, so it will continue to receive security fixes for > OpenJDK 8 throughout its supported lifetime. > > Debian 10 (buster), currently prerelease, will ship with > OpenJDK 11, and thus receive updates for OpenJDK 11. > > stretch-backports is a suite which corresponds to backports > of those packages that are, at the time of backporting, in > buster. “backports” here basically means that the exact(!) > package is rebuilt in the previous distribution, and the only > allowed changes are those necessary to make it build and work > there. Debian backports also operate under the expectation > that, whenever a new version is uploaded to or migrates¹ to > the origin suite, the backport will be updated (or removed, > if backporting is no longer possible). > > Now, buster is still prerelease, which means that the packages > in stretch-backports are also prerelease right now. (We’re > expecting to release within $smallnum weeks, though.) But they > will eventually be identical to what will be shipped with, and > supported in, buster. > > ① “migrate”: the testing distribution is a bit of special case, > as packages are not normally directly uploaded there, but to > unstable first and then migrate after a period of time in which > bugs can be identified, and it will not migrate if it depends > on any other packages that cannot migrate (unless the version > already in testing satisfies the dependency). > > > Now I’m not involved in what actually goes into the packages > in the first place, but the plan (a bit taken off path by the > ftpmasters misinterpreting a removal request for some builds > of OpenJDK 8 in unstable as a request to remove OpenJDK 8 in > its entirety) is to prepare updated versions of all supported > JDKs in unstable, then, when no problems are shown, to upload > those to oldstable-security or stable-security or testing² as > needed, and then (following backports policy) updating the > backports accordingly (oldstable-backports from stable-security, > stable-backports from testing). > > ② normally by letting it migrate, or, during pre-release freeze, > requesting an unblock to allow the package to migrate > > > The intent is to package stable versions for actual Debian > releases, then apply necessary security fixes afterwards > (because in Debian, we never³ introduce new versions into > an already released version as part of the stability promise). > > I assume part of the problem is the difficulty of identifying > what’s stable (and get the corresponding addons for e.g. the > ARM architectures), but, as doko said, trust the content, not > the label. Versions of software Debian ships don’t necessarily > correspond to the versions in other distributions of the same > software, but they are those tested and integrated with the > rest of the distribution, and those that will be supported by > the Debian maintainers and security team. > > As a user, I’d rather have a, say, 8u212 upstream prerelease > that’s supported by the security team (and that works for our > use cases in building and running software in Java™, and that > integrates with the rest of the software shipped by Debian) > than to blindly install new upstream versions, especially if > those introduce regressions. (It was bad enough when those > JAR manifest “security” patches broke builds for ages.) > > ③ This is not entirely true, admittedly: for select software, > such as “modern” web browsers, where supporting the versions > in stable over the lifetime of a release is not possible at > all, new versions are allowed into stable-security, but this > deviates from both the security and the stability promises > and is communicated to users as a compromise (we rather ship > an unsupported but recent version than none at all, so our > users may get the software) but we prefer to do that only > when the regular way of retrofitting security updates only > is not at all possible. > > For OpenJDK and some other softwares, it is understood that > upstream branches containing only security fixes for the > released version is acceptable for uploads of “new” versions > (as long as those are really security and critical bug fixes > only, not new versions or features; and even then, sometimes > things break in a bad way, which we’d like to avoid). > > Ah, and here comes the reasoning why an 8u212 prerelease is > no problem (as long as it’ll eventually be replaced by the > actual release or something newer): when an upstream branch > is considered to be comprised of only security and critica > bug fixes, the releases upstream cuts off that branch are > just snapshots at some given point in time, and a prerelease > would be just as stable, as surely upstream would only have > applied a patch to that branch only if it addresses either > a security problem or a critical bug and it had already been > tested in the latest development/feature branch. (Does this > make sense? If not, please DO tell, and I’ll try to explain > some more, as this is a core point and somewhat critical.) > > > Full disclosure: I’m a Debian Developer and maintainer of a > couple of packages, but not of any of the core Java packages. > In my dayjob, I’m a user of those, package some fringe ones > and occasionally help out. > > Please listen to doko for anything authoritative to OpenJDK > packaging, and for anything to do with Canonical/Ubuntu with > which I have nothing to do. > > > Something else to keep in mind: all this talking about a > specific “build” of Java, as that Azul person does, cannot > apply to Debian as we always build all software shipped in > Debian ourselves from source code. So it’s best to avoid > using the word “build” when discussing something with Debian. > > I think terms that correspond to specific statuses of the > source code trees and branches would work better instead. > > bye, > //mirabilos > -- > tarent solutions GmbH > Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ > Tel: +49 228 54881-393 • Fax: +49 228 54881-235 > HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 > Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander > Steeg > > ********** > > Mit der tarent Academy bieten wir auch Trainings und Schulungen in den > Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an. > > Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren > Kontakt. > > ********** >
