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
