Thomas Goirand dijo [Wed, Oct 20, 2021 at 10:51:59PM +0200]: > >> That's obviously what I'm doing. But when there's 2 releases during the > >> freeze, it means one of them will never reach Unstable. > > > > Right, which makes perfect sense. > (...) > > I guess very few will, but if it's needed, it's available -- and > > the work for you when the freeze is done is much smaller (just > > re-target changelog, re-build, re-upload). > > > > What do you lose by those uploads not reaching unstable? > > Very simple: an upgrade path. In most OpenStack projects, you cannot > skip an OpenStack release, at least because of the db schema upgrades.
Uff, that sounds quite ugly :-( ...And what about providing Openstack packages whose name includes the version, as Linux or PostgreSQL do? that way, if OpenStack releases twice a year and Debian every two years, Debian X can include the four OpenStack releases that have happened since Debian X-1... Or you can continue running your previous OpenStack release if you so want, for some extra years. It would be up to the sysadmin to jump from OpenStack a→b→c→d before upgrading to Debian X+1 (which ships with e, f, g, h). It seems as very little gain for the huge framework that OpenStack is. Now, OTOH, distribution maintainers could work together to pick migrations. If you can pick all the needed bits from the d→e migration and apply them in your postinst (if upgrading from d to f), you can effectively skip going through e. Of course, picking the migrations for every OpenStack release could allow you to build intelligent (although probably obese) maintainer scripts able to perform the needed updates you have, a→d, d→g, etc. I guess I'm just stating obvious bits... and that the OpenStack complexity would make this obviously harder. But if the process is automatizable, it is doable (of course, with enough developer resources). And fleshing out the needed migrations would benefit not only Debian, but every distribution carrying non-consecutive OpenStack packages.