On Mon, Sep 9, 2019 at 5:10 PM Adam Williamson <adamw...@fedoraproject.org> wrote:
> On Mon, 2019-09-09 at 15:19 +0200, Vendula Poncova wrote: > > On Fri, Sep 6, 2019 at 3:02 AM Adam Williamson < > adamw...@fedoraproject.org> > > 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? > > > > > > > Hi Adam, > > > > I think that the best option is to add a new storage validation check > that > > will report a warning if a user wants to use a file system that is not > > recommended by the installed product. The list of recommended file > systems > > would be provided by the Anaconda configuration files, so products and > > variants could override it. > > > > We already show warnings with recommendations, for example for too small > > root partition or missing swap. The storage validation checks are run for > > every type of partitioning, results are logged and warnings have to be > > waved by the user in the interactive mode. > > This could work, however it's what I'd call "backwards UI" (I'm sure > there's a real term for it, but I'm not an expert so I don't know what > it is) - it's a pattern I find annoying because it makes you make > choices *before you know what the constraints are*, then tells you you > broke the mystery rules you didn't know about. ;) It's like password > systems that just say 'enter a password', then you enter one, and > *then* it says 'oh BTW it's meant to have more than 8 characters', so > you enter one with more than 8 characters and it says 'oh yeah and one > of them has to be upper case', so you upper case one, then it says 'oh > yeah and one has to be a special character', then you shoot the PC and > go herd yaks...:P > Warnings inform you about potential risks of your choices, but you are allowed to ignore them unlike the error messages you are talking about. It is like, when you enter a password with non-ASCII characters, the password system can say 'be careful, you might not be able to switch a keyboard layout when typing it', but you can still go ahead and use your password anyway. I would expect that users in general know what they are doing (I thought that is the premise of the Custom Partitioning Spoke), so I understand the warning about unsupported file systems as a disclaimer. -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net > http://www.happyassassin.net > > _______________________________________________ > Anaconda-devel-list mailing list > Anaconda-devel-list@redhat.com > https://www.redhat.com/mailman/listinfo/anaconda-devel-list >
_______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
