also sprach Russ Allbery <r...@debian.org> [2013.01.24.1856 +1300]: > I always understood that I had a responsibility as a backporter to release > security fixes as necessary, and if I wasn't going to do that, I shouldn't > upload the backport in the first place. I handle backport security fixes > exactly the way that I handle stable security fixes.
So if a software is at 1.0 in stable and you backported 1.1~bpo60.1 from testing, and then a security flaw is found in all 1.x releases which was fixed in 2.0, and meanwhile 2.2 is in testing, will you backport the security fix to 1.1 and release 1.1~bpo60.2? And say that a year later 2.3 comes out and it's the bee's knees because it fully replaces 1.1 except that the configuration cannot be automatically migrated, and all the power users on #debian-devel persuade you to backport it, what do you do? In my experience, once a software is backported, there's a much smaller threshold to backport newer versions. In fact, I have been exposed to software that was backported within minutes after the parent package migrated to testing, probably just for the sake of providing cutting-edge versions to users. I feel that more software goes through the backports archive because of new features and updates that wouldn't pass our stable release policy, than security fixes to previously backported software. And yet, setting "ButAutomaticUpdates: yes" pretends that it's the other way around. -- .''`. martin f. krafft <madduck@d.o> Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduck http://vcs-pkg.org `- Debian - when you have better things to do than fixing systems "what's your conceptual continuity? -- well, it should be easy to see: the crux of the bisquit is the apopstrophe!" -- frank zappa
digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
