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

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

 



> From: awilliam@xxxxxxxxxx
> 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

-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux