Re: Discussion: what would not blocking on btrfs look like?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Sep 09, 2019 at 01:43:00PM -0400, David Lehman wrote:
> 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.
> 

Why bother hiding it at all?  I get that there's no btrfs expertise at Red Hat,
but there's not any reason to indicate that it's bad for the user to choose it.
Suse ships it, all of Facebook is on it, it's not like we're talking about hfs+
here or anything.  I get the discussions around wether it's a release blocker, I
don't really understand why the installer needs to be changed?  Thanks,

Josef

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list



[Index of Archives]     [Kickstart]     [Fedora Users]     [Fedora Legacy List]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]
  Powered by Linux