<tt><font size=2>> From: awilliam@redhat.com</font></tt>
<br><tt><font size=2>> Date: 02/21/2014 15:20</font></tt>
<br><tt><font size=2>> Historically, QA and anaconda more or less agreed
on an approach whereby<br>
> the 'guided' partitioning path would be expected to work extremely<br>
> reliably: QA would undertake to test every (well, nearly every) route<br>
> through that path regularly and proactively, and anaconda would<br>
> undertake to fix the bugs. Custom partitioning was much more of a<br>
> 'bonus' thing: if it worked, great. QA would test it as much as we
had<br>
> time for, and anaconda would fix as many bugs as they could after
fixing<br>
> higher priority stuff. I went back and looked at the history, and
in the<br>
> earlier days of Fedora, the guided path was consciously designed to
be<br>
> very 'choice free'.</font></tt>
<br>
<br><tt><font size=2>That makes a lot of sense, but I'd like to add that
when doing custom partitioning, you can easily spend the bulk of your actual
interaction time getting the partitioning customized exactly the way you
want and when anaconda crashes, it's not much fun to loose that effort.
I've had this happen lots and still do. Unfortunately, I can
never see the pattern to file a BZ for it. One thing I've generally
learned *not to do* is click on something for exploration purposes only.
I'm trying to think of a good example, but maybe I want to see what
the btrfs layout looks like. Okay, but lets go back and take the
default now. Poof!</font></tt>
<br>
<br><tt><font size=2>> With the best of intentions, we'd gone from a
reluctant exception to the<br>
> 'no choice' design to a dropdown which included two very different<br>
> complex choices: LVM and btrfs. So now the installer path which was<br>
> originally supposed to be minimal-choice, very robust and testable
and<br>
> fixable, had become rather a lot more complex.</font></tt>
<br>
<br><tt><font size=2>Everything should be made as simple as possible, but
not simpler. I appreciate your QA angle here. Every condition
in a code path leads to exponential growth in testing. However, when
I have my admin hat on, I want flexibility. I love LVM for that reason.
However, if I'm setting up simple VMs whose backend storage resides
in a LV, I have no need or desire for LVM within the VM. It only
makes more work if I have to do an in place resize later on. Having
LVM on those host makes that resizing oh so much simpler though, especially
if additional drives are required.</font></tt>
<br>
<br><tt><font size=2>I feel much the same about the /home partitioning
and wish there was an checkbox in anaconda for that. Having a separate
/home partition is good practice, but I never use the feature because mine
is on NFS, so it makes for lots of click work to get the auto layout, then
remove the home. (I did learn accidentally with btrfs I can just
ignore it and I've not lost any space on /.)</font></tt>
<br>
<br><tt><font size=2>So yes, simplicity is good, unless it makes everything
else harder later.</font></tt>
<br><font size=2 face="sans-serif"><br>
--<br>
John Florian</font>
<br>