[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Proposal: Repository for fast-paced package backports

On 26/12/2018 19:31, Dominik George wrote:

   - 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.)
Of course you can use testing without having sid available, that's the point of testing[1]. I think there's a misunderstand about testing lurking here, too. And the requirement of backports for the package to be in testing is also to get a sane upgrade path from stable to next-stable. So you have to support your thing alongside testing, too. At least during the freeze, but optimally shortly after the release has been cut. 


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.
For backports the general supportability assumption is that you provide a sane upgrade path from stable to the backports and from the backport to the next stable (optimally the same package). Once you take the presence of the stable package out of the mix, it becomes weird. How long do you need to preserve compatibility code? How does an agile package that does not fit Debian's release cycle cater to these requirements?
Just discounting that on the grounds of "that's normal for backporting" if it's unique to your proposal is not quite satisfactory to me. 

Kind regards
Philipp Kern
[1] You can make the argument that there's a problem with security update. But that's why the urgency system exists and maintainers can declare that a certain package needs to migrate with minimal waiting time. And most of the time (not always) the exploits start to materialize later.
Reply to: