Sub-backports?

[Steffen Möller <steffen_moeller@gmx.de>]

For Debian Med we have a similar situation, not as bad though, as with
the Django packages: Strong inter-dependencies between packages. This
happens whenever there is some kind of framework has a non-monotonic
feature change. Our Django is R.  It is mostly fine, but when we are not
careful, then an update of R in backports would require many other
packages to compile or to be updated. And when we say that we support a
particular version of BioConductor, which depends on a particular
version of R, then we have to somehow do just that have the right
versions of packages together because that is what this version of
BioConductor is having. And we have all the same problems (or would have
if we would do backports) when the release of BioConductor is not in
sync with the release of Debian.

Take home message of the above: Django is not alone.

I am not exactly sure about what we should do about it all. I just see
some further scenarios:
 * go through testing is fine, but what do we do while we are in a freeze?
 * what when we want to offer multiple version of Django/BioConductor
with their very own sets of versions of associated packages?

I am with Alex (my past AM, hello) that the current policy has mostly
worked. But I also tend to think that we need something for communities
that have their very own understanding of what a release is that is
mostly independent from the underlying OS. Ubuntu can get there via
their PPA infrastructure but I find that confusing since the user does
not know what PPA to trust and which not so much. My subject line was a
bit of a provocation, but could we think about a concept that would both
be close to the distribution and allow for the needs of particular user
community?

Best,

Steffen