On Mon, 04 Jun 2018 16:41:29 +1000 Dmitry Smirnov <onlyjob@debian.org> wrote: > On Monday, 4 June 2018 4:01:27 PM AEST Alexander Wirt wrote: > > When its not ready for stable, its not ready for backports. All > > those reasons against stable apply to backports too. > > You are wrong. Backports is for something that you could use on > "stable" but can't because it is not in "stable". Backports can be used for that, yes. > Notably we use > backports for newer versions of software but it would be silly to say > that older version of that software must already be in "stable". However, it is a requirement that the *same* version is already in testing before adding the backport for current stable. This is clear in the docs on the backports site. If you're asking for an exception, telling one of the people who can grant such an exception that he's flat out wrong (when he's not) isn't going to help things. > Clearly this particular reason against stable doe not apply to > backports because backports can be updated at any time when > necessary. Subject to the normal *testing* migration cycle. This rule applies because testing is the next stable, hence the original comment - if your package is not ready for testing (it is not) then it is not ready for the next stable and is also not ready for current stable backports. > And it is great that we can use backports when we need to > bypass normal stable release cycle > - that's precisely what backports are for. Not unless the *testing* migration cycle has been completed. -- Neil Williams home@codehelp.co.uk
Attachment:
pgpY4RQYUllIz.pgp
Description: OpenPGP digital signature