By the way, here are the official criteria from the Debian Developer's Reference Manual[1]:
Extra care should be taken when uploading to stable. Basically, a package should only be uploaded to stable if one of the following happens: * a truly critical functionality problem * the package becomes uninstallable * a released architecture lacks the package [1] https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#upload-stable This bug just doesn't qualify. "critical" is defined as: makes unrelated software on the system (or the whole system) break, or causes serious data loss, or introduces a security hole on systems where you install the package.[2] Where as the lower-priority bug "grave" is defined as: makes the package in question unusable or mostly so, or causes data loss, or introduces a security hole allowing access to the accounts of users who use the package.[2] [2] https://www.debian.org/Bugs/Developer This bug is at *best* grave*, because it only corrupts a small number of files (those that have holes --- hence, not "serious" data loss) and only if the user uses a fairly exotic feature which you have to manually specify, by hand, from a root shell. Given how unlikely it will be for people to run into this, it could easily be argued that this would be "important" or "normal". And per the developer's reference manual, the release team doesn't get out of bed for stable updates for anything lower that "truly critical functionality problems". I will note that these are criteria more strict than what Red Hat uses for RHEL, but <shrug>. There's a reason why I only use Debian Stable^H^H^H^H^H Obsolete for really simple services, such as DNS, IMAP, Web servers, etc. If I'm going to use any kind of advanced or exotic features, the very restrictive definition of allowable bug fixes that are currently defined for Stable make it (IMHO) a bad idea. If you want bug fixes that aren't quite at the "truly critical functionality problem" level, the only answer we have today is Debian Backports. Personally, I think Debian as an organization has drawn the line for Stable inclusion in completely the wrong place. By being so concerned about not letting any regressions through, to the point that debdeffs have to be submitted to the Debian Release Team for their low-level, detailed approval, and making Maintainers jump through hoops, bugs aren't getting fixed --- even "important" or "grave" bugs. But Debian is a volunteer organization, and I've never cared enough to really push on this. Best regards, - Ted P.S. I actually go through a fair amount of work to make sure the e2fsprogs Debian source package will continue to build on stable and oldstable, although recent initiatives to force the use of newer debhelper compat levels hav made this more difficult. So if people want to build the very latest version of e2fsprogs on older Debian releases, this is not hard, and this is what I as the upstream maintainer would recommend. It's not what the Debian Release Team considers acceptable, but: ¯\_(ツ)_/¯
