Fwd: Re: default file system, was: Comparison to Workstation Technical Specification

Mon Mar 3 17:40:21 UTC 2014

> On Mon, Mar 03, 2014 at 09:22:53AM -0500, Stephen Gallagher wrote:
>> On 03/03/2014 09:16 AM, Ric Wheeler wrote:
>>> On 03/03/2014 04:06 PM, Josef Bacik wrote:
>>>> On Mon, Mar 3, 2014 at 8:59 AM, Stephen Gallagher
>>>> <sgallagh at redhat.com> wrote:
>>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>>>>
>>>>> On 03/03/2014 08:51 AM, Ric Wheeler wrote:
>>>>>> On 03/03/2014 03:43 PM, Stephen Gallagher wrote:
>>>>>>> So if you were asking me "Are we removing btrfs from the
>>>>>>> install options completely?", the answer is a resounding
>>>>>>> "NO". However, if you're asking "Are we removing btrfs from
>>>>>>> the drop-down of simple-install layouts?", my personal
>>>>>>> recommendation is "yes".
>>>>>> I disagree - why would we remove the drop down option?
>>>>>>
>>>>>> That would make it exceedingly hard and rare for casual users
>>>>>> to install and test.  Basically, our Fedora btrfs user base
>>>>>> would drop to nothing.
>>>>>>
>>>>>> Making it easy to test is a critical part of taking btrfs up
>>>>>> to the next level of stability!
>>>>>>
>>>>> It's a matter of user experience, here. By presenting something
>>>>> in the guided drop-down, we are effectively asserting that they
>>>>> are of equal utility and support. This is *not* the reality.
>>>>>
>>>>> Now, if you want to talk about having some sort of
>>>>> click-through for "I want to try out some experimental options
>>>>> without going all the way to customizing my layout manually",
>>>>> that (to me) needs to be a different, third path. But listing
>>>>> it directly alongside the default gives a false expectation.
>>>>>
>>>>> Now, this might be as simple as changing the modern drop-down
>>>>> from * EXT4 * BTRFS * XFS [] Use LVM
>>>>>
>>>>> To something like: * XFS-LVM (Recommended) * XFS * EXT4-LVM *
>>>>> EXT4 * BTRFS (Experimental)
>>>>>
>>>>> But even still, Fedora QA is at least ostensibly supposed to
>>>>> test all guided paths and best-effort of custom paths. This is
>>>>> more paths than are strictly necessary, especially considering
>>>>> that we don't expect many people to actually USE the guided
>>>>> paths (in favor of custom and/or kickstart).
>>>> Ok I was just confused as I haven't done a normal install in a
>>>> few releases.  So you can still get to btrfs going through some
>>>> new "custom layout" option but you want to remove the "install
>>>> onto btrfs" easy button in the normal guided option?  I'm ok with
>>>> this, I just want to make sure that I/users don't have to jump
>>>> through icantbelieveitsnotbtr hoops to install onto btrfs.
>>>> Thanks,
>>>>
>>>> Josef
>>> I am fine with something like what is proposed by Steve above -
>>> let users have the GUI present an option that gives preference to
>>> the default without totally hiding other options.
>>>
>> To be clear, I don't really like that option at all. I was presenting
>> it to show how it's not a great user experience. That being said, if
>> everyone else (and especially QA) prefers that approach, I'm certainly
>> flexible on the point.
>>
>> I'm really hoping that the design, user experience, anaconda and QA
>> teams will make their opinions on this known. I know full well that
>> this is not my area of expertise. BCCing a few specific individuals to
>> hopefully get their input.
> I agree with Stephen here, assuming I'm understanding him correctly.  When
> you talk about choices in a UI, you start exponentially increasing the
> number of paths to do basically the same thing.
>
> Exposing a filesystem choice to users really degrades the user experience.
> Does everyone know what a filesystem is?  And if they know, do they know
> what the options are that we are presenting them?  Do they know the pros and
> the cons between them?  Do they really care that much?
>
> To me it sounds like the goal here is to advertise other filesystem options
> in the hopes that we get some drive-by interest by people doing first time
> installs.  10 years of bug reports tell me that people just don't care about
> that option.  A default is exactly that, a default.  We should pick a good
> default that is well supported across all of the architectures that we care
> about in Fedora.  By exposing a filesystem selection option at install time,
> we're really saying we have that many defaults.  Oh, and we need you to
> understand them so you can pick one.  Most people would probably leave that
> option alone, which begs the question: why have it at all?
>
> It's 2014 and we're still holding on to BTRFS as the solution to all of our
> filesystem problems.  That's fine, but it hasn't happened yet.  And as long
> as that's the story, we should expose something that's actually usable and
> recommended at install time.  I really see no value in offering slightly
> different filesystem options at install time.  If we want something
> different, it should become the new default.
>
> (For clarification, the above is speaking about the automatic partitioning
> code path, not custom partitioning.  Custom will likely always involve more
> knobs and controls for users, and many filesystem types.  But that's ok,
> custom is for those users.)
>

I am fine with having the custom partitioning be the place to deviate from the 
defaults...

Ric

Speaking from experience, any new users to Fedora are really not going to know what an fs is, let alone which one would be best to pick. IMHO it really only confuses new people and would not really make them want to stick around long enough to figure out what an fs is all about. The "advanced setting/manual partioning" is something that tells the new guy there should probably be a little more study or thought put into what they are doing.  I believe that would be the place to give someone an option, not default settings on a guided path.

Danny

Sent from my U.S. Cellular® Smartphone

-------- Original message --------
From: Ric Wheeler <rwheeler at redhat.com> 
Date:03/03/2014  9:48 AM  (GMT-06:00) 
To: devel at lists.fedoraproject.org 
Subject: Re: default file system, was: Comparison to Workstation Technical
 	Specification 

On 03/03/2014 04:40 PM, David Cantrell wrote:
> On Mon, Mar 03, 2014 at 09:22:53AM -0500, Stephen Gallagher wrote:
>> On 03/03/2014 09:16 AM, Ric Wheeler wrote:
>>> On 03/03/2014 04:06 PM, Josef Bacik wrote:
>>>> On Mon, Mar 3, 2014 at 8:59 AM, Stephen Gallagher
>>>> <sgallagh at redhat.com> wrote:
>>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>>>>
>>>>> On 03/03/2014 08:51 AM, Ric Wheeler wrote:
>>>>>> On 03/03/2014 03:43 PM, Stephen Gallagher wrote:
>>>>>>> So if you were asking me "Are we removing btrfs from the
>>>>>>> install options completely?", the answer is a resounding
>>>>>>> "NO". However, if you're asking "Are we removing btrfs from
>>>>>>> the drop-down of simple-install layouts?", my personal
>>>>>>> recommendation is "yes".
>>>>>> I disagree - why would we remove the drop down option?
>>>>>>
>>>>>> That would make it exceedingly hard and rare for casual users
>>>>>> to install and test.  Basically, our Fedora btrfs user base
>>>>>> would drop to nothing.
>>>>>>
>>>>>> Making it easy to test is a critical part of taking btrfs up
>>>>>> to the next level of stability!
>>>>>>
>>>>> It's a matter of user experience, here. By presenting something
>>>>> in the guided drop-down, we are effectively asserting that they
>>>>> are of equal utility and support. This is *not* the reality.
>>>>>
>>>>> Now, if you want to talk about having some sort of
>>>>> click-through for "I want to try out some experimental options
>>>>> without going all the way to customizing my layout manually",
>>>>> that (to me) needs to be a different, third path. But listing
>>>>> it directly alongside the default gives a false expectation.
>>>>>
>>>>> Now, this might be as simple as changing the modern drop-down
>>>>> from * EXT4 * BTRFS * XFS [] Use LVM
>>>>>
>>>>> To something like: * XFS-LVM (Recommended) * XFS * EXT4-LVM *
>>>>> EXT4 * BTRFS (Experimental)
>>>>>
>>>>> But even still, Fedora QA is at least ostensibly supposed to
>>>>> test all guided paths and best-effort of custom paths. This is
>>>>> more paths than are strictly necessary, especially considering
>>>>> that we don't expect many people to actually USE the guided
>>>>> paths (in favor of custom and/or kickstart).
>>>> Ok I was just confused as I haven't done a normal install in a
>>>> few releases.  So you can still get to btrfs going through some
>>>> new "custom layout" option but you want to remove the "install
>>>> onto btrfs" easy button in the normal guided option?  I'm ok with
>>>> this, I just want to make sure that I/users don't have to jump
>>>> through icantbelieveitsnotbtr hoops to install onto btrfs.
>>>> Thanks,
>>>>
>>>> Josef
>>> I am fine with something like what is proposed by Steve above -
>>> let users have the GUI present an option that gives preference to
>>> the default without totally hiding other options.
>>>
>> To be clear, I don't really like that option at all. I was presenting
>> it to show how it's not a great user experience. That being said, if
>> everyone else (and especially QA) prefers that approach, I'm certainly
>> flexible on the point.
>>
>> I'm really hoping that the design, user experience, anaconda and QA
>> teams will make their opinions on this known. I know full well that
>> this is not my area of expertise. BCCing a few specific individuals to
>> hopefully get their input.
> I agree with Stephen here, assuming I'm understanding him correctly.  When
> you talk about choices in a UI, you start exponentially increasing the
> number of paths to do basically the same thing.
>
> Exposing a filesystem choice to users really degrades the user experience.
> Does everyone know what a filesystem is?  And if they know, do they know
> what the options are that we are presenting them?  Do they know the pros and
> the cons between them?  Do they really care that much?
>
> To me it sounds like the goal here is to advertise other filesystem options
> in the hopes that we get some drive-by interest by people doing first time
> installs.  10 years of bug reports tell me that people just don't care about
> that option.  A default is exactly that, a default.  We should pick a good
> default that is well supported across all of the architectures that we care
> about in Fedora.  By exposing a filesystem selection option at install time,
> we're really saying we have that many defaults.  Oh, and we need you to
> understand them so you can pick one.  Most people would probably leave that
> option alone, which begs the question: why have it at all?
>
> It's 2014 and we're still holding on to BTRFS as the solution to all of our
> filesystem problems.  That's fine, but it hasn't happened yet.  And as long
> as that's the story, we should expose something that's actually usable and
> recommended at install time.  I really see no value in offering slightly
> different filesystem options at install time.  If we want something
> different, it should become the new default.
>
> (For clarification, the above is speaking about the automatic partitioning
> code path, not custom partitioning.  Custom will likely always involve more
> knobs and controls for users, and many filesystem types.  But that's ok,
> custom is for those users.)
>

I am fine with having the custom partitioning be the place to deviate from the 
defaults...

Ric

-- 
devel mailing list
devel at lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140303/68422b05/attachment.html>