Re: Proposal: Repository for fast-paced package backports
On 12/26/18 8:16 PM, Dominik George wrote:
>> 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?
>
> This is wrong, at least in a big part.
It's completely, fully, right. I very much subscribe to all of what
you've quoted from Philipp Kern.
> The stable release cycle does not apply for -backports.
It very much does. Backports are opened when Stable is released, and
closed when Stable is EOL (and there's no backports for LTS, ATM). So
backports are exactly following the lifecycle of a given stable release.
Or do you mean something else here?
> A package in -backports can be udpated an
> arbitrary number of times during the development window of stable+1
And if there's any problem during any of the upgrades, it can be
considered a bug and shall be fixed, by all means! And any upgrades you
may think of. Like stable -> backports, or backports -> testing, or even
from one version of the backport to the next.
> If you take into account edge cases, where a package is removed from
> testing during the freeze, is removed from -backports as a result, is
> not released with stable+1, then gets fixed and reintroduced to testing
Normally, this does not happen. If a package is removed from testing
during the freeze, then it's not re-introduced.
BTW, could you *please* stop calling what you want as "volatile"? Each
time I see it, I think of stable-updates, that's *very* confusing.
Cheers,
Thomas Goirand (zigo)
Reply to: