Re: Proposal: Repository for fast-paced package backports

[Dominik George <natureshadow@debian.org>]

Hi,

>I would, however, completely separate it from backports. I.e.
>
> - separate NEW queue
> - different suffix
> - no need to keep a volatile package out of testing
>
>Why?
>
> - volatile is a different beast from backports, this should be
>   very clear to both package maintainers and our users

The idea is to have them separated, but fully interoperable.

I.e. the proposal ensures such things as:

- foo is not supportable for the buster release cycle. It goes to volatile.
- foo becomes supportable for buster+2.
- foo is backported (as in -backports) to buster+1

This will work properly, among other such scenari.

> - volatile must not put any burden on the backports team, which
>   e.g. a common NEW queue would probably impose

The whole point is that it is not new work or a new burden. This is one reason for the rules being almost the same and the clear decision path and movement between -backports and -volatile. A -volatile package is handled exactly the same, except it comes from unstable. The workload is the same as if the package had migrated to testing and was being uploaded to -backports. The defined preconditions ensure this is not abused for a ton of packages.

-nik