On Mon, Sep 9, 2019 at 5:10 PM Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx> wrote:
On Mon, 2019-09-09 at 15:19 +0200, Vendula Poncova wrote:
> On Fri, Sep 6, 2019 at 3:02 AM Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx>
> 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@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
