On Wed, 2017-05-24 at 12:49 +0200, Raphael Hertzog wrote: > [ The topic here is maintaining a version X in $foo-backports when $foo+1 > contains a version higher than X, eg in my case keep maintaing Django > 1.8.x in jessie-backports while stretch has 1.10.x ] > > Hello, > > let's start a proper discussion based on facts. The other thread > has gotten needlessly personal. I want to start with what I said > in https://lists.debian.org/debian-backports/2017/05/msg00106.html > > The reason for the reject of my upload was "please take the version from > testing, not a version that never was in the archive". But the rules > > (https://backports.debian.org/Contribute/) say this: > > To guarantee an upgrade path from stable+backports to the next stable, > > the package should be in testing. > > Note the "should", it's not a "must". And my upload perfectly met the > criteria for that suggestion: my backported package upgrades fine to > the next stable. > > The policy goes further by defining exceptions: > > Of course there are some exceptions: Security updates. > > I initially uploaded a version that was in testing and all the subsequent > uploads I made were security updates (in the form of upstream point > releases). > > Honestly, I really think that I'm fully in the spirit of the backport > policy and that this rejection is unwarranted. [...] I've always understood that the exceptional cases justify backporting a newer version that is currently only in unstable, not an older version. I think we should have an additional exception for cases where it becomes impractical to backport newer versions but a maintainer is willing to support it with important fixes. But from what I've read, that doesn't seem to be the case with Django 1.10. Ben. -- Ben Hutchings In a hierarchy, every employee tends to rise to his level of incompetence.
Attachment:
signature.asc
Description: This is a digitally signed message part