[Base] Fedora Base Design Working Group (2014-02-21) meeting minutes and logs

[John.Florian at dart.biz]

> From: awilliam at redhat.com
> Date: 02/21/2014 15:20
> Historically, QA and anaconda more or less agreed on an approach whereby
> the 'guided' partitioning path would be expected to work extremely
> reliably: QA would undertake to test every (well, nearly every) route
> through that path regularly and proactively, and anaconda would
> undertake to fix the bugs. Custom partitioning was much more of a
> 'bonus' thing: if it worked, great. QA would test it as much as we had
> time for, and anaconda would fix as many bugs as they could after fixing
> higher priority stuff. I went back and looked at the history, and in the
> earlier days of Fedora, the guided path was consciously designed to be
> very 'choice free'.

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!

> With the best of intentions, we'd gone from a reluctant exception to the
> 'no choice' design to a dropdown which included two very different
> complex choices: LVM and btrfs. So now the installer path which was
> originally supposed to be minimal-choice, very robust and testable and
> fixable, had become rather a lot more complex.

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.

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 /.)

So yes, simplicity is good, unless it makes everything else harder later.

--
John Florian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140221/7d6cae77/attachment.html>