Re: backports during the freeze
On Thu, 23 Feb 2017 at 15:41:45 +0000, Athanasius wrote:
> Just to note that Experimental is an even worse idea for backports
> than Unstable. See: <https://wiki.debian.org/DebianExperimental>
Well, it depends. During the freeze, some packages in experimental are
of a quality that would go to unstable if there wasn't a freeze in effect,
while others are unfinished and, yes, sometimes dangerous.
The maintainer of the package knows which is which, but unrelated
contributors don't necessarily. So random contributors backporting
from experimental without talking to the normal (non-backport) maintainer
would be a bad idea, but if the package's normal maintainers have OK'd it,
it could be fine.
Some concrete examples:
- ostree 2017.1-1 in experimental is not inherently any less stable than
ostree 2016.15-3 in unstable (both are just the latest upstream release
from the time they were packaged), but 2016.15 was released before the
freeze and 2017.1 after, and we have to draw a line somewhere
- I don't know mpd in detail, but I suspect that similarly, mpd 0.20.4
is not significantly less stable than 0.19.21, just too new
but conversely:
- dbus 1.10.x in testing/unstable is a bugfix-only branch,
whereas dbus 1.11.x in experimental is a development branch
(1.11.x will only go to unstable when they reach beta/rc status for
the 1.12.x stable-branch)
- glib2.0 2.50.x and 2.51.x are in the same situation as dbus (they use
the same versioning model)
- openjk is only in experimental, and has never actually had an
upstream release (stable or otherwise)
so the latter group of packages shouldn't be backported from experimental.
(I personally think backporters should always be in regular contact with
the normal maintainer anyway, and should probably be Uploaders, but not
everyone has that opinion.)
Regards,
S
Reply to: