> > - The package must not be in testing, and care must be taken for the > > package not to migrate to testing. > So what would a user of testing do? Will there be a $codename-volatile[1] > suite for testing users? Or would they directly install unstable with no > other pre-release staging ground? (Which seems like a bad idea.) The testing distribution and this concept contradict each other. The testing distribution is the least supported stage in the Debian release cycle, and if used, shall only be used for testing the next Debian release. Especially, there are no timely security updates in testing, neither by the security nor by the maintainer. So using it for anything other than testing the next Debian release in a laboratory is a bad idea. This proposal, however, is about providing fast-paced software as an exception on an otherwise stable system. So if anyone wants to test fast-paced software within a Debian testing system, they should use the package from unstable, yes. (Having testing on a system without the sid zources is close to impossible outside the freeze anyway.) > > Similarly what are the constraints you set for upgrading, if any? How far > back will upgrades work and how current do users need to keep their system > in order to still be able to upgrade? For one, I think you will need to set > expectations here towards the maintainers if a package is never included in > a stable release, as they get very muddy otherwise. Plus you need to set > expectations for the users as the next package (maybe not gitlab) might come > up with requirements that upgrades need to go through every version on the > way to, say, update the database properly. And that's hardly supportable > unless everyone knows to update quickly. That certainly is something maintainers need to care about. (I consider a software not supporting skipping versions on upgrade a bug, anyway.) But most importantly, this is nothing that is specific to the -volatile proposal - it is the same for regular backports. So discussing this general backporting issue should not be mixed with the discussion of this proposal. -nik
Attachment:
signature.asc
Description: PGP signature