On Mon, 04 Jun 2018 20:29:32 +1000 Dmitry Smirnov <onlyjob@debian.org> wrote: > On Monday, 4 June 2018 7:43:51 PM AEST Rhonda D'Vine wrote: > > > This is really a minor concern and it wouldn't even be valid if we > > > continue backporting for next release. > > > > Oh, it very well is, because the upgrade path that we want to > > ensure is from oldstable+backports to currentstable without > > backports. You might consider it minor yourself, but it's not to > > us. > > I find it hard to believe. Having no upgrade path versus having no > backport at all? But backported software could be useful regardless > of upgrade path. > > Backported software may never make it to next release after upload to > backports... That's the entire point - it should and it needs to support the upgrade to the version in that next release. backports is not a bikeshed or dumping ground for stuff you would rather not have to host yourself. There are reasons why backports exists and packages entering backports must comply. If you don't like it, host an archive on your own space. > > That package get removed and discontinued is what kind of > > reasoning to not try to offer a proper upgrade path in the first > > place? Sorry, I can't follow what you say at all. > > The point is that you never know if there will be an upgrade path at > all. Of course it is good to aim at potential upgrade path but IMHO > uncertainty in regards to future upgrade path shouldn't invalidate > immediately useful backport. One can never be sure about future > upgrade path as many things may change during release cycle. That's why the package must exist in testing - that is part of the upgrade path assurance. -- Neil Williams home@codehelp.co.uk
Attachment:
pgpGK3FMXNDnX.pgp
Description: OpenPGP digital signature