Re: Proposal: Repository for fast-paced package backports
>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
> - 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.