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 day. 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 dropdown. 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 exhaustively. 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' custom. 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 alternatives. 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 non-custom path. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
