On Fri, Aug 23, 2019 at 9:17 PM Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx> wrote: > > Hey folks! > > So, there was recently a Thing where btrfs installs were broken, and > this got accepted as a release blocker: > > https://bugzilla.redhat.com/show_bug.cgi?id=1733388 > > The bug was fixed, so that's fine, but along the way, Laura said this: > > "I'm strongly against anything with btrfs being a blocker. If that's in > the criteria I think we should see about removing btrfs simply because > we don't have the resources to actually deal with btrfs besides > reporting bugs upstream." > > and Justin followed up with: > > "Agreed, btrfs has been a gamble pretty much always. See previous > discussion around proposals to make btrfs default. Ext4 and xfs should > be the only release blocking." > > So, that's the whole kernel team 'strongly against' blocking on btrfs. > Which means we should talk about not doing that any more! > > This is a bit complicated, though, because of how the Final criteria > are phrased. Basic does not include btrfs at all, and Beta includes a > laundry list we can just remove btrfs from: > > "When using both the installer-native and the blivet-gui-based custom > partitioning flow, the installer must be able to: > > * Correctly interpret, and modify as described below, any disk with a > valid ms-dos or gpt disk label and partition table containing ext4 > partitions, LVM and/or btrfs volumes, and/or software RAID arrays at > RAID levels 0, 1 and 5 containing ext4 partitions > * Create mount points backed by ext4 partitions, LVM volumes or btrfs > volumes, or software RAID arrays at RAID levels 0, 1 and 5 containing > ext4 partitions > ..." > > so those two are easy. However, the Final criterion is not laundry > list-style. The relevant Final criterion is this: > > "The installer must be able to create and install to any workable > partition layout using any file system and/or container format > combination offered in a default installer configuration." > > with a somewhat apologetic explanatory footnote: > > "Wait, what? > Yeah, we know. This is a huge catch-all criterion and it's subject to a > lot of on-the-fly interpretation. Broadly what it's 'meant to mean' is > that you should be able to do anything sane that the Installation > Destination spoke attempts to let you do, without the installer > exploding or failing. We are trying to write more specific criteria > covering this area, but it's not easy. Patches welcome, as the kids > say..." > > so as the footnote says, the rule is basically "if the installer lets > you do it, it ought to work". It seems a bit awkward to craft an > exception for btrfs from that. I mean, technically it's easy: > > "The installer must be able to create and install to any workable > partition layout using any file system and/or container format > combination offered in a default installer configuration, except > btrfs." > > but that's odd. Why is btrfs, alone, an exception? It kinda goes > against the fundamental idea of the criterion: that we stand behind > everything the UI offers. > > So...what should we do? Here are the options as I see 'em: > > 1. Keep supporting btrfs > 2. Just modify the criterion with a btrfs exception, even if it's weird > 3. Rewrite the criterion entirely > 4. Keep btrfs support in the installer (and blivet-gui) but hide it as > we used to - require a special boot argument for it to be visible > 5. Drop btrfs support from the installer > > I'm bringing this to anaconda, kernel and test teams initially to kick > around; if we agree on an approach we should then probably loop in > devel@ for wider review, unless the choice is 1). This thread has diverged wildly into a lot of delightful invective-slinging at my team. In the interest of getting back to the original topic at hand: I would be in support of three -- five. Thanks for bringing this topic up, Adam, and for presenting this list of options. > > Thanks for any thoughts, folks! > -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net > http://www.happyassassin.net > _______________________________________________ > test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to test-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/test@xxxxxxxxxxxxxxxxxxxxxxx -- Samantha N. Bueno Manager, Platform Engineering Red Hat, Inc | Boston, MA _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
