[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian distributions of stable OpenJDK updates

On Sun, 26 May 2019, Matthias Klose wrote:

> >> In general, I think it would be helpful for our users if we uploaded the
> >> prereleases to experimental but stuck to GA releases for unstable,
> >> testing, and backports.  I think it is easy to mistake, for example, an
> >> 11.0.3+x (prerelease) version in Debian with the 11.0.3 GA release being

It would help if prereleases did not use the ‘+’ character.

Perhaps an upstream mangling in debian/watch to replace it with ‘~pre’
or ‘~ea’ or so might help?

> >> distributed by other projects.
> I would like to avoid experimental, because it really doesn't get much testing.

What about using unstable/testing/stable-backports for preleases until
the soft (not hard, so we have some time) freeze, then tracking only
releases, so a frozen testing, stable-backports during time of the
freeze, stable and oldstable-backports have releases only?

>  See the openjdk-11 updates as a stable release branch, and it's worth to check

That’s a good argument against the previous paragraph, and it matches
what I wrote earlier in the other thread:

| 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

To me, this makes just as much sense.

Perhaps, shipping upstream prereleases really isn’t a problem
(trust the content, not the label), but labelling them clearly
(see the above comment about an upstream mangling rule in the
watch file) might please all but the weirdest (that Azul guy)
people; after all, if it’s really a fix-only branch, it’s in
the interest of our users to get the fixes out fast without
waiting for an upstream release (possibly).

> these out early, because upstream doesn't test most Debian architectures.

And that’s a good argument in favour of packaging them up for
unstable and testing them there, widely (especially as some of
the ports architectures’ buildds don’t often get around to
building experimental).

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.


Reply to: