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.

Reply via email to