On 26 February 2017 at 17:12, Jonathan Wiltshire <j...@debian.org> wrote: > Control: tag -1 moreinfo > > On Tue, Feb 14, 2017 at 11:31:06AM +0000, Dimitri John Ledkov wrote: >> Roses are red, >> Violets are blue, >> This will not rhyme, >> Please unblock package btrfs-progs >> >> This is late; I am a twat; it is full of bugfixes; and should match >> kernel version we are going to ship. > > You probably already guessed I am not very impressed by this. >
I think nobody is impressed by it. > What are the consequences of it not matching? > The largest consequence socially is a bunch of angry users who read btrfs wiki page which advocates running a matching version of btrfs-progs for a given kernel version, despite lack of actual hard coupling. At the same time, those users often run backported kernels and a backports version of btrfs-progs (not maintained/uploaded by me). Notwithstanding bug fixes, and people re-reporting bugs against stable which are known to be fixed in v4.9.1, on normal usage things mostly use (e.g. one can mount/upgrade/create use current testing btrfs-progs with v4.9 kernels) Excluding tests / documentation updates / refactoring there are: * removal of using v1 defrag ioctl, and thus enforcing v2 defrag ioctl (available since v2.6.33 kernel) * low memory fixes * many NULL pointer fixes in check/clone/receive >> $ git log v4.7.3..v4.9.1 --oneline > oneline.txt | wc -l >> 438 > > That's ridiculous, you can't seriously think that's appropriate when > other packages are being turned down for fewer changes. The anticipated > kernel version has hardly been a secret. Indeed, it was not a secret. But there was a lack of time for me to prepare and review this update in time for the freeze. -- Regards, Dimitri.