On Mon, Aug 26, 2019 at 10:48 PM Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: > > On Fri, Aug 23, 2019 at 1:44 PM Justin Forbes <jmforbes@xxxxxxxxxxx> wrote: > > > > All of this, the criteria, and the UI support for btrfs are from the > > many years old proposal to make btrfs the default filesystem. In the > > beginning, it was not ready, but did show promise. This proposal came > > up for several releases in a row, and at the end of it, even the > > upstream developers recommended against it. > > Josef Bacik alone pushed for it. And it was Fedora that wasn't ready > for Btrfs, not the other way around. In Josef's last couple emails to > devel@ he stated the decision would need to be made by others, not > him. He pretty much gave up once SUSE got there first. > Indeed. In fact, I more or less took over the reigns of trying to improve Fedora's Btrfs support after Josef gave up. > I'm not aware of any upstream developers recommending Fedora not use > it. A significant chunk of upstream are at SUSE and by this time had > moved to Btrfs by default, so it'd be a little weird if they're > recommending against the thing. > If anything, the Btrfs stack developers at SUSE have been nothing but helpful whenever I've talked to them about working on bringing this to Fedora. I've literally *never* heard them say that Btrfs isn't ready. However, they have told me in the past to be cautious with some features for "enterprise supportability". But they've never said anything about Btrfs not being ready as a whole. > > > At this point, it is safe > > to say that btrfs will not be the default. Since that time, things > > have not gotten better. > > This is ambiguous. One possible way to read this is: no matter what > resources are put into supporting it in Fedora, it's safe to say it > won't be the default. Another possibility: the support resources > necessary haven't materialized, therefore it won't be the default. > > I would like to better understand why it is "safe to say" it won't be > the default. > I really didn't want this to come up, and I ignored this the first time, but I can't anymore... I'm pretty sure this is another variation of the "shutdowns" I keep getting when trying to work on Btrfs support in Fedora. It's surprisingly annoying that Fedora as a community distribution has touch points where community members have basically zero chance at being successful at anything. Honestly, I'm surprised we've kept Anaconda as the installer for Fedora, given the attitude I and other community members get from the Anaconda developers and sheer amount of pain and agony we have to deal with to even attempt simple contributions, much less complex ones. Amazingly, I do have a single commit in Anaconda[0], but the amount of effort and time it took to get it in was ridiculous. And while I like the Anaconda installer, I don't like that there can never be a community around it. It's one of those projects that has a stranglehold around it that is designed to discourage you. And that's not even with things like Btrfs. There's been a request (with code even!) from the Qubes OS folks to add GPG key support to kickstart[1] and Anaconda[2] for literally years. I've wanted to accept the changes for livecd-tools[3] for years, but I can't until pykickstart and anaconda support it. I'm not even going to get into the repo --priority option from the FedBerry guys. By any meaningful measure, Anaconda has less community than Btrfs, and it remains the "blessed" installer. Moreover, it gets to singlehandedly dictate what the distribution supports. And its developers basically get to shut down any discussion of anything related to Btrfs, in any form or fashion[4]. And you wonder why Btrfs support is so weak in Fedora? Because of all this, I was discouraged from finishing and submitting my change proposal to fully enable Btrfs with full system snapshots[5]. I'm honestly not surprised that Josef gave up. I'm surprised that I'm still stubborn enough to try to make it happen, but perhaps there's a part of me that hates giving up... [0]: https://github.com/rhinstaller/anaconda/commit/c8c5589e4a4c5451d91ae8c47bf2fe0270d2af5f [1]: https://github.com/bcl/pykickstart/pull/32 [2]: https://github.com/rhinstaller/anaconda/pull/375 [3]: https://github.com/livecd-tools/livecd-tools/pull/14 [4]: https://bugzilla.redhat.com/show_bug.cgi?id=1717728#c9 [5]: https://fedoraproject.org/wiki/Changes/BtrfsWithFullSystemSnapshots > > > > > Yes, there is active btrfs development > > upstream. It is fairly narrowly focused, and not something we can > > rely upon for a supported default among the Fedora use cases. > > The thread is ostensibly about whether it's appropriate to block > release on Btrfs related bugs, not whether it should be the default > file system. But as it's been brought up, I'd like to know if there's > any difference in the expected support resources between it remaining > "blocker worthy" versus becoming "a default file system" somewhere in > the Fedora ecosystem in a release blocking capacity (i.e. presumably a > Fedora Spin could choose to make Btrfs its default file system, but > that wouldn't be release blocking). > > I can unequivocally say if I were allowed to, I would have a Fedora Spin that used Btrfs by default. But for the reasons outlined above, I don't think I'll ever be allowed to. > > While > > Fedora does enable it in the kernel, and plans to continue doing so, > > it is enabled in the "if you break it, you get to keep the pieces" > > method of many other options. Sure, we will be happy to bring in a > > patch that is headed upstream if it fixes a bug, and someone points us > > to it. No, we aren't going to spend time debugging issues with it > > ourselves. There is no shortage of issues in more "core" kernel > > pieces that require attention. > > That's understandable and reasonable. I don't think anyone > uninterested in supporting Btrfs should be made to feel like they > ought to. Life is short, do what you're interested in doing, no more. > At the same time, actively strangling others' ability to do what they want is unhelpful and against the community spirit that Fedora is supposed to have. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@xxxxxxxxxxxxxxxxxxxxxxx
