On Tue, Aug 27, 2019 at 1:02 PM David Cantrell <dcantrell(a)redhat.com> wrote:
On 8/27/19 2:00 PM, Chris Murphy wrote:
> The Fedora working group's technical specification states Btrfs is to
> be the default. Yet the working group has said it's uncomfortable
> taking action on this decision expressly because the Federal kernel
> team's official recommendation is to not recommend Btrfs. And I agree.
> I trust the Fedora kernel team as they've clearly stated limited
> resources and interest in Btrfs, the expectations and parameters for
> properly supporting Btrfs either as bug blocker worthy, and as a
> default file system from a user advocacy point of view.
OK, so 8 years has gone by and the landscape around btrfs looks
different in Fedora. Given the kernel team's position, is it worth
still having the FESCo decision and kernel team's recommendation at odds?
They aren't at odds.
8 years ago FESCo decision on Btrfs
5 years ago Workstation working group decision on Btrfs (their
requirements and specs docs were signed off by FESCo)
3 years ago kernel team said while they don't recommend it, they
acknowledged it was ultimately up to the working group to decide, and
noted they were sick of having this conversation every release
The Workstation working group has, correctly in my view, put their own
decision in abeyance, as a result of the kernel team's official
recommendation. How does the Btrfs landscape in Fedora look different
to you in three years?
The way the landscape looks different to me:
One, the possibility of getting a kernel engineer who works on Btrfs
to join the Fedora kernel team, so that the team has the capacity to
support and recommend (at least as a team, not that any individual
needs to give up one tiny bit of their Btrfs scepticism) is an
Two, that in the interim, Red Hat is where the landscape has really
changed has occurred with respect to Btrfs, and I see indications of
this bias being injected back into Fedora: suggesting that a Red Hat
shift away from Btrfs somehow is actually a Fedora shift away from
Btrfs, suggesting a do over vote in the Workstation working group, or
even an undo vote by FESCo to set aside the Workstation working group
And to what end? All that's needed is for the Anaconda team to
provided the same courtesy of clear expectations and parameters, as
the kernel team has done.
>> If it's a best effort thing, then that makes it easier for
>> projects and contributors. Going back to Adam's original list, I would
>> suggest a FESCo decision like this should require explicit opt-in by the
>> user to enable btrfs functionality in the application in question. For
>> example, in the installer that could be enabled via a boot parameter (we
>> did this initially when btrfs functionality was first enabled in anaconda).
> That can only be considered to be a remarkable regression, not just in
> the context of Fedora, but in the context of the top 10 linux
> distributions all of which have visible Btrfs support in their GUI
> installers. Fedora's installer being the first to make Btrfs invisible
> by default would be a remarkable first indeed.
I'm merely offering an example scenario.
This does illustrate a problem with expectations among users. It's
visible now, but not a priority, which leads to frustration.
Just like today's kernel team, Anaconda today are not obligated to
make it a priority. But qualifying what "not a priority" actually
means is necessary. The question is what are the preconditions for
others who will make it a priority? And whether Anaconda is going to
slow walk every PR that tries to improve Btrfs support? What about
simplifying the Btrfs support in Anaconda to make it easier to
maintain with priority parity with other file systems? Gut all the
multiple device stuff, perhaps? Btrfs can easily do quite a lot of
adjustments post-install, it's one of it's most central features. Few
options are mkfs only.
>> I'm not advocating one way or another for btrfs. But it
seems we as a
>> project need a larger decision and policy around btrfs in general so we
>> can set expectations for users and developers.
> That decision and policy has already been made. Do you want it reverted?
I guess I meant to say "FESCo needs to revisit this decision for a
I can't parse this. Which decision, and what potential change?