[Date Prev][Date Next] [Thread Prev][Thread Next]
Re: Idea for making custom partitioning more accessible
- From: Adam Williamson <awilliam redhat com>
- To: Discussion of Development and Customization of the Red Hat Linux Installer <anaconda-devel-list redhat com>
- Subject: Re: Idea for making custom partitioning more accessible
- Date: Thu, 19 Dec 2013 11:05:14 -0800
On Fri, 2013-10-25 at 16:44 -0700, Adam Williamson wrote:
> > 2) You click 'Done' in the upper left corner. You go straight to the
> > hub. Yeh. So basically:
> > http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Sketches/Straight-To-CustomPart/dialog1.png
> > Anything you would have been able to do in the dialog you already did in
> > the main window. Except for choosing auto-part type. If you're not going
> > into custom part, is the default auto-part type good enough? If not, the
> > main screen design will need more thinking.
> I hate to be Neddy Negative, but I fear it may not be good enough, no.
> We have the new LVM Thin Provisioning thing available in F20 which
> presumably was put in this way because we want people to be able to use
> it without creating a whole custom layout. We have this idea that we
> want people to be able to test btrfs so we can maybe make it the default
> in future. And we definitely have an annoying bunch of LVM refuseniks
> who will always pick ext4 because they 'understand how to deal with it'
> and don't want to learn LVM. I'm afraid I'm not convinced we can get
> away with 'defaults only' :/ But, see later!
Heh, it's funny I happened to come back to this thread while replying to
a forum post, because cmurf and I were discussing this just the other
I may want to change my mind about this one, at least partly.
So we were trying to draw up a storage validation matrix which would let
us at least test non-custom partitioning methodically and somewhere
close to exhaustively, and when we try that, it quickly becomes obvious
that one of the complicating factors is the partition/volume type.
Basically, it's a multiplying factor: we have to find every path through
guided partitioning, and then if we want to be thorough, we have to run
each of those tests (currently) four times: one for each option on the
I went back and looked at how, historically, we've got to this point,
and it was actually kind of interesting.
In Ye Olde Times, we actually fairly clearly intended for non-custom
partitioning to be pretty choice-free. The broad design was that you
picked disks, got the 'approaches' question screen - "do you want to
wipe all data? only use empty space? wipe only existing Linux
partitions? or resize a partition?" - and that was pretty much it as far
as choice went, unless you picked Custom.
We also had a clear split in testing: QA had a set of test cases
intended to test all the 'choice' paths and all the various disk types
anaconda supported, and this was designed to give assurance that the
non-custom path was solid. Testing on custom part was much more
'optional extra' stuff, and there was no attempt at all to test it
So, back a while ago, we actually had a fairly clear 'line in the sand'
that was a part of anaconda's design and reflected in our testing
process: 'non-custom' partitioning was a fairly choice-free affair which
we tried quite hard to make sure always worked; you could use custom if
you liked, but we didn't guarantee it would never break.
Since then the lines have gotten a bit blurred. On the QA side we're now
testing custom part a lot harder than we used to, and setting a higher
bar for it (probably unrealistically high, which is one of the things
we're working on). And I think both anaconda and QA unintentionally lost
sight of the original clear vision for a split between 'simple,
choice-free, reliable' non-custom and 'all choices here, bugs may occur'
I think as long as non-custom simply gave you LVM and you liked it,
there was a contingent which was unhappy with this and kept complaining
about it. Eventually, a compromise was made: oldUI non-custom got a
'don't use LVM' checkbox.
Then I think what happened next was this got improved - from a design
perspective - in newUI. A checkbox which is basically a filesystem
selector doesn't make an awful lot of sense from a UI pov, so it was
turned into a dropdown, which is a much better UI. But the checkbox also
kind of encoded a hint about the nature of the option - that it was an
ad-hoc compromise, not really a part of the design. The dropdown lost
this, and I think we all sort of forgot about it, I know I did.
Right at the start of newUI, we added btrfs to that dropdown, which
means we've now got 3x the paths through non-custom part. And F20 added
lvm thinp, which makes it 4x. btrfs and lvm thinp are also far less
'safe' than ext4 as alternatives to the default LVM; it's pretty unusual
for plain ext4 to break where LVM works - it's almost a perfect subset,
really - but much more plausible that btrfs or thinp might. So instead
of one 'default path' with a reluctantly-tacked-on but probably safe
alternative, we have a default path with three alternatives that look
'equally blessed', two of which add considerable potential for
problematic divergent behaviour compared to the default.
Sorry for the history lesson, but I found it instructive to look back
over the history of how we got here, and I thought others might too.
All this does rather support the idea of dropping or at least reducing
the range of filesystem Choice on the non-custom path, so I'm certainly
less opposed to the idea now than I was before. In theoretical terms,
the purest options are 'go back to just one default' or 'keep adding
stuff when we want to, and accept that our model is now that non-custom
part is more flexible and possibly less bulletproof'. But in practical
terms, I actually think the late-oldUI approach of offering LVM as the
default with ext4 as a 'reluctant alternative' has a bit to be said for
it. I can certainly see dropping btrfs and thinp as non-custom
cmurf suggested that we should either make thinp just what you get when
you pick LVM, or downgrade it to a custom partitioning choice: offering
it as an alternative to 'plain' LVM doesn't seem to fit very well. Using
thinp while it's not the default seems to be a fairly advanced choice
that probably doesn't need to be offered this visibly through the
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
[Date Prev][Date Next] [Thread Prev][Thread Next]