Re: Btrfs progs release 4.16.1
David Sterba posted on Wed, 25 Apr 2018 13:02:34 +0200 as excerpted: > On Wed, Apr 25, 2018 at 06:31:20AM +, Duncan wrote: >> David Sterba posted on Tue, 24 Apr 2018 13:58:57 +0200 as excerpted: >> >> > btrfs-progs version 4.16.1 have been released. This is a bugfix >> > release. >> > >> > Changes: >> > >> > * remove obsolete tools: btrfs-debug-tree, btrfs-zero-log, >> > btrfs-show-super, btrfs-calc-size >> >> Cue the admin-side gripes about developer definitions of micro-upgrade >> explicit "bugfix release" that allow disappearance of "obsolete tools". >> >> Arguably such removals can be expected in a "feature release", but >> shouldn't surprise unsuspecting admins doing a micro-version upgrade >> that's specifically billed as a "bugfix release". > > A major version release would be a better time for the removal, I agree > and should have considered that. > > However, the tools have been obsoleted for a long time (since 2015 or > 2016) so I wonder if the deprecation warnings have been ignored by the > admins all the time. Indeed, in practice, anybody still using the stand-alone tools in a current version has been ignoring deprecation warnings for awhile, and the difference between 4.16.1 and 4.17(.0) isn't likely to make much of a difference to them. It's just that from here anyway, if I did a big multi-version upgrade and saw tools go missing I'd expect it, and if I did an upgrade from 4.16 to 4.17 I'd expect it and blame myself for not getting with the program sooner. But on an upgrade from 4.16 to 4.16.1, furthermore, an explicit "bugfix release", I'd be annoyed with upstream when they went missing, because it's just not expected in such a minor release, particularly when it's an explicit "bugfix release". >> (Further support for btrfs being "still stabilizing, not yet fully >> stable and mature." But development mode habits need to end >> /sometime/, if stability is indeed a goal.) > > What happened here was a bad release management decision, a minor one in > my oppinion but I hear your complaint and will keep that in mind for > future releases. That's all I was after. A mere trifle indeed in the filesystem context where there's a real chance that bugs can eat data, but equally trivially held off for a .0 release. What's behind is done, but it can and should be used to inform the future, and I simply mentioned it here with the goal /of/ informing future release decisions. To the extent that it does so, my post accomplished its purpose. =:^) Seems my way of saying that ended up coming across way more negative than intended. So I have some changes to make in the way I handle things in the future as well. =:^) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Btrfs progs release 4.16.1
On 2018-04-25 07:29, Christoph Anton Mitterer wrote: On Wed, 2018-04-25 at 07:22 -0400, Austin S. Hemmelgarn wrote: While I can understand Duncan's point here, I'm inclined to agree with David Same from my side... and I run a multi-PiB storage site (though not with btrfs). Cosmetically one shouldn't do this in a bugfix release, this should have really no impact on the real world. The typical sysadmin will anyway use some stable distribution... and is there any which ships already 4.16? Arch, Gentoo, and Void all have it ATM, but whether or not you want to consider them stable is another question. OpenSUSE Tumbleweed and Fedora Rawhide also have 4.16, though those are also of questionable stability. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Btrfs progs release 4.16.1
On Wed, 2018-04-25 at 07:22 -0400, Austin S. Hemmelgarn wrote: > While I can understand Duncan's point here, I'm inclined to agree > with > David Same from my side... and I run a multi-PiB storage site (though not with btrfs). Cosmetically one shouldn't do this in a bugfix release, this should have really no impact on the real world. The typical sysadmin will anyway use some stable distribution... and is there any which ships already 4.16? Cheers, Chris. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Btrfs progs release 4.16.1
On 2018-04-25 07:02, David Sterba wrote: On Wed, Apr 25, 2018 at 06:31:20AM +, Duncan wrote: David Sterba posted on Tue, 24 Apr 2018 13:58:57 +0200 as excerpted: btrfs-progs version 4.16.1 have been released. This is a bugfix release. Changes: * remove obsolete tools: btrfs-debug-tree, btrfs-zero-log, btrfs-show-super, btrfs-calc-size Cue the admin-side gripes about developer definitions of micro-upgrade explicit "bugfix release" that allow disappearance of "obsolete tools". Arguably such removals can be expected in a "feature release", but shouldn't surprise unsuspecting admins doing a micro-version upgrade that's specifically billed as a "bugfix release". A major version release would be a better time for the removal, I agree and should have considered that. However, the tools have been obsoleted for a long time (since 2015 or 2016) so I wonder if the deprecation warnings have been ignored by the admins all the time. While I can understand Duncan's point here, I'm inclined to agree with David, with the further addendum that these are all debug tools, and therefore no sane sysadmin should be depending on them for production operation anyway. (Further support for btrfs being "still stabilizing, not yet fully stable and mature." But development mode habits need to end /sometime/, if stability is indeed a goal.) What happened here was a bad release management decision, a minor one in my oppinion but I hear your complaint and will keep that in mind for future releases. Do you really want to use that to perpetuate the 'still stabilizing and not mature' claim? If you expect 0 bugs and essentially no other visible problems, than I don't think you should use linux. Or wait until it's fully stable, whatever that means. I think you mean 'I don't think you should use computers', given that other platforms are just as bad in slightly different ways. In terms of features, btrfs is not done and will be actively developed and maintained. Bugs will be found, reported and fixed, new features will add more code that will have to be stabilized over time. This is how the entire linux kernel evolves. The focus in recent releases has been on cleanups and refactoring, besides bugfixes. No big feature has been merged, to some disappointment of developers and users, but this is namely to minimize the fallout of new code that does not have enough review and testing. My target is to do slow and steady incremental changes with no regressions. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Btrfs progs release 4.16.1
On Wed, Apr 25, 2018 at 06:31:20AM +, Duncan wrote: > David Sterba posted on Tue, 24 Apr 2018 13:58:57 +0200 as excerpted: > > > btrfs-progs version 4.16.1 have been released. This is a bugfix > > release. > > > > Changes: > > > > * remove obsolete tools: btrfs-debug-tree, btrfs-zero-log, > > btrfs-show-super, btrfs-calc-size > > Cue the admin-side gripes about developer definitions of micro-upgrade > explicit "bugfix release" that allow disappearance of "obsolete tools". > > Arguably such removals can be expected in a "feature release", but > shouldn't surprise unsuspecting admins doing a micro-version upgrade > that's specifically billed as a "bugfix release". A major version release would be a better time for the removal, I agree and should have considered that. However, the tools have been obsoleted for a long time (since 2015 or 2016) so I wonder if the deprecation warnings have been ignored by the admins all the time. > (Further support for btrfs being "still stabilizing, not yet fully stable > and mature." But development mode habits need to end /sometime/, if > stability is indeed a goal.) What happened here was a bad release management decision, a minor one in my oppinion but I hear your complaint and will keep that in mind for future releases. Do you really want to use that to perpetuate the 'still stabilizing and not mature' claim? If you expect 0 bugs and essentially no other visible problems, than I don't think you should use linux. Or wait until it's fully stable, whatever that means. In terms of features, btrfs is not done and will be actively developed and maintained. Bugs will be found, reported and fixed, new features will add more code that will have to be stabilized over time. This is how the entire linux kernel evolves. The focus in recent releases has been on cleanups and refactoring, besides bugfixes. No big feature has been merged, to some disappointment of developers and users, but this is namely to minimize the fallout of new code that does not have enough review and testing. My target is to do slow and steady incremental changes with no regressions. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Btrfs progs release 4.16.1
David Sterba posted on Tue, 24 Apr 2018 13:58:57 +0200 as excerpted: > btrfs-progs version 4.16.1 have been released. This is a bugfix > release. > > Changes: > > * remove obsolete tools: btrfs-debug-tree, btrfs-zero-log, > btrfs-show-super, btrfs-calc-size Cue the admin-side gripes about developer definitions of micro-upgrade explicit "bugfix release" that allow disappearance of "obsolete tools". Arguably such removals can be expected in a "feature release", but shouldn't surprise unsuspecting admins doing a micro-version upgrade that's specifically billed as a "bugfix release". (Further support for btrfs being "still stabilizing, not yet fully stable and mature." But development mode habits need to end /sometime/, if stability is indeed a goal.) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Btrfs progs release 4.16.1
Hi, btrfs-progs version 4.16.1 have been released. This is a bugfix release. Changes: * remove obsolete tools: btrfs-debug-tree, btrfs-zero-log, btrfs-show-super, btrfs-calc-size * sb-mod: new debugging tool to edit superblock items * mkfs: detect if thin-provisioned device does not have enough space * check: don't try to verify checksums on metadata dump images * build: fail documentation build if xmlto is not found * build: fix build of btrfs.static Tarballs: https://www.kernel.org/pub/linux/kernel/people/kdave/btrfs-progs/ Git: git://git.kernel.org/pub/scm/linux/kernel/git/kdave/btrfs-progs.git Shortlog: Baruch Siach (1): btrfs-progs: build btrfs.static needs libbtrfsutil to build David Sterba (5): btrfs-progs: sb-mod: add preliminary support for non-u64 types btrfs-progs: sb-mod: add csum_type btrfs-progs: sb-mod: add compat bit to the recognized fields btrfs-progs: reorder extent buffer members for better packing btrfs-progs: update CHANGES for v4.16.1 Gu Jinxiang (4): btrfs-progs: send-utils: remove unused functions path_cat and path_cat3 btrfs-progs: Let function find_device to be consistent with kernel btrfs-progs: Remove duplicate value-get for data_extents_scrubbed btrfs-progs: Do not add extra slash if given path end with it Misono Tomohiro (1): btrfs-progs: configure: check if xmlto exists at configure time Nikolay Borisov (4): btrfs-progs: Remove btrfs-debug-tree command btrfs-progs: Remove deprecated btrfs-zero-log standalone tool btrfs-progs: Remove deprecated btrfs-show-super btrfs-progs: Remove deprecated btrfs-calc-size tool Qu Wenruo (9): btrfs-progs: check: Skip data csum verification for metadata dump btrfs-progs: tests/fsck: Add test case to check if btrfs check can skip data csum verfication for metadata dump btrfs-progs: extent_io: Fix NULL pointer dereference in free_extent_buffer_final() btrfs-progs: extent_io: Init eb->lru to avoid NULL pointer dereference btrfs-progs: extent_io: Refactor alloc_extent_buffer() to follow kernel parameters btrfs-progs: Unify btrfs_leaf_free_space() parameter with kernel btrfs-progs: print-tree: Remove btrfs_root parameter btrfs-progs: Rename OPEN_CTREE_FS_PARTIAL to OPEN_CTREE_TEMPORARY_SUPER btrfs-progs: Use more loose open ctree flags for dump-tree and restore Su Yue (1): btrfs-progs: mkfs: return nozero value on thin provisioned device -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
