From: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>
To: dsterba@suse.cz, Duncan <1i5t5.duncan@cox.net>,
linux-btrfs@vger.kernel.org
Subject: Re: Btrfs progs release 4.16.1
Date: Wed, 25 Apr 2018 07:22:32 -0400 [thread overview]
Message-ID: <64535388-9024-087c-3d67-4425cd4b0292@gmail.com> (raw)
In-Reply-To: <20180425110234.GN21272@twin.jikos.cz>
On 2018-04-25 07:02, David Sterba wrote:
> On Wed, Apr 25, 2018 at 06:31:20AM +0000, 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.
next prev parent reply other threads:[~2018-04-25 11:22 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-24 11:58 Btrfs progs release 4.16.1 David Sterba
2018-04-25 6:31 ` Duncan
2018-04-25 11:02 ` David Sterba
2018-04-25 11:22 ` Austin S. Hemmelgarn [this message]
2018-04-25 11:29 ` Christoph Anton Mitterer
2018-04-25 11:49 ` Austin S. Hemmelgarn
2018-04-25 17:56 ` Duncan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=64535388-9024-087c-3d67-4425cd4b0292@gmail.com \
--to=ahferroin7@gmail.com \
--cc=1i5t5.duncan@cox.net \
--cc=dsterba@suse.cz \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox