On 25/12/2018 21:46, Dominik George wrote:
Requirements for a package to go into stable-volatile
=====================================================
The new volatile proposal is not intended to ease life for package
maintainers who want to bypass the migration and QA requirements of the
regular stable lifecycle, so special need must be taken to ensure only
packages that need it go into volatile. I want to summarise the
requirements like so:
- The package must be maintained in unstable, like every other package.
- The package must not be in testing, and care must be taken for the
package not to migrate to testing.
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.
Kind regards Philipp Kern[1] I would like to re-register my objection to that name for the same reason Holger stated: it is confusing to reuse an older name (which, by the way, started outside of Debian, too and was then merged in) with a new concept.