On Tue, Dec 25, 2018 at 11:52:07PM +0100, Dominik George wrote: > Hi, > > >having read the whole Gitlab discussion, I still don't get how/why the > >new repository depends or relates to backports. Instead it could be > >self-contained, except for stuff already available in stable. Couldn't > >you roll the new repository entirely independent of any backports? Even > >if you say there won't be any additional work for the backport policy > >owners, letting a new repo depend on backports will implicitly have an > >impact, which doesn't sound fully thought through yet. > > This is answered in the proposal. The reason is to not have volatile > abused to ease backporting, and to allow packages to easily move back to > backports again.
Just to make things a bit clearer for people who may not have followed
some of the discussions on d-bp-users lately: the point is to be able to
support fast-moving software with not-so-fast moving dependencies;
the dependencies may easily be backported without too large a burden
(their versions will not come too often, so they will be able to migrate
to testing and thus fulfil the criteria for being in backports), while
the main piece of software moves too fast, including across major
versions and with incompatible changes, so that it is not suitable for
being included in a stable release (thus the part in the proposal about
blocking its migration to testing).
The maintainers of the stack will first package the dependencies, wait
for them to migrate to testing, then backport them, and then they will
upload the main piece of software first to unstable and then to the new
suite under discussion.
G'luck,
Peter
--
Peter Pentchev roam@{ringlet.net,debian.org,FreeBSD.org} p...@storpool.com
PGP key: http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
signature.asc
Description: PGP signature
