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.
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.)
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.
