On Tue, 2019-08-27 at 16:54 -0600, Chris Murphy wrote: > 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. Removing something from Anaconda to replace it by BTRFS functionality doesn't really help. It would even make our lives harder. The point is that the same code has to be there because of the RHEL so it would only diverge our effort that everything have to be done twice. > > > > > > 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 _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
