On Tue, Aug 27, 2019 at 1:02 PM David Cantrell <dcantrell@xxxxxxxxxx> 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 important development. 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 vote. 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 > potential change". I can't parse this. Which decision, and what potential change? -- Chris Murphy _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
