On Thu, 2019-09-05 at 18:01 -0700, Adam Williamson wrote: > On Tue, 2019-09-03 at 13:38 -0400, David Lehman wrote: > > On Fri, 2019-08-23 at 12:16 -0700, Adam Williamson wrote: > > > Hey folks! > > > > Hi Adam! Thanks for bringing this up again. > > > > > 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 like option 3 most. The current criteria have always seemed, to > > me, > > too vague. I'd be happy to help hash out the details if/when it > > happens. > > Thanks for the offer. > > So aside from the 'fun' of drafting very specific rules, my concern > with #3 is we would then potentially be shipping an installer that > presents things as roughly equal choices which are not in fact > equally > supported. You can pick 'btrfs' or 'ext4' from the dropdown...but one > of those we commit to making sure is working, one of them we don't. > That to me is concerning; in this scenario I'd prefer we indicate > somehow, somewhere, that all the choices are not equally guaranteed > to > be reliable. WDYT? Two off-the-cuff ideas: 1. every fs (and device?) type in the combo/dropdown has "(Supported)" or "(Unsupported)" postfix, eg: "xfs (Supported)" or "BTRFS (Unsupported)" 2. every unsupported fs type has a corresponding kernel arg, eg: "inst.btrfs" or "inst.fs.btrfs" which is required to get that unsupported fs type in the GUI list I could live with either, personally. David _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
