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
_______________________________________________
kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to kernel-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/kernel@xxxxxxxxxxxxxxxxxxxxxxx




[Index of Archives]     [Fedora General Discussion]     [Older Fedora Users Archive]     [Fedora Advisory Board]     [Fedora Security]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Mentors]     [Fedora Package Announce]     [Fedora Package Review]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Coolkey]     [Yum Users]     [Tux]     [Yosemite News]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [USB]     [Asterisk PBX]

  Powered by Linux