On Feb 19, 2014, at 6:07 PM, Adam Williamson <awilliam@xxxxxxxxxx> wrote: > On Wed, 2014-02-19 at 16:55 -0700, Chris Murphy wrote: > >> If the bar is going to be raised, > > Just as a sidebar, I'm not sure you're entirely on track with this > assessment - I haven't quite read the same 'undertone' into the .next > discussions. I don't have a way to qualify the magnitude of the raising. So whether it's static or is raised, and if raised then by how much, is something sufficiently open ended right now that it needs to be made more clear. Or I need remedial attention. > >> then my instinct is to be even more aggressive with how the installer >> should only present recommended or at least sane outcomes to users. It >> probably shouldn't ever crash. > > I don't think you'll get this past the devs. IIRC, their position is > that it is best to crash with a useful traceback in any case where you > somehow wind up in a situation where the installer is not completely > confident about what's going on, for two reasons: > > 1) they only want installation to proceed if they are very confident it > will work correctly > 2) it helps to fix problems, because they get much / all of the > necessary information from the bug reporting process > > They're generally very reluctant to have anaconda try to 'sweep things > under the carpet and just go ahead anyway' when it runs into problems, > for the above two reasons. I completely understand that argument, and especially post-beta I've supported rough edges in the installer not being blockers because of realism. But *if* the bar is being raised, I think there's a necessary commensurate change (and thus a risk) that the installer is going to have to be held to a higher standard too. And if that's not tenable, what I'd say is that to get to better stability is to chop out peripheral, esoteric outcomes that are maybe "nice to haves" or "bad ass" but really aren't strictly necessary. After all this is about getting an OS installed that works. 80 outcomes?! Is that really necessary? I don't think we get to say the bar is being raised while the installer gets to offer marginally popular layouts, themselves probably edge cases, that then result in confusing dead ends, crashes, or don't boot after install. Such bugs are effectively fixed by simply disallowing those paths. The resources are then spent maturing more common paths. Otherwise it's just a free for all, and quite honestly that's where I think the installer has been headed. It's not being given that much opportunity since newui to stabilize because new stuff keeps getting added. So I think a triage mentality needs to take over even before the context is Fedora.next let alone if Fedora.next decides a higher bar. > >> We probably should have *one* file system option for Guided >> partitioning, which is the recommended layout, and the user gets to >> choose a couple of variations: encryption, and a way to reuse an >> existing /home. > > Based on the last discussion on anaconda-devel, I'm not sure we can get > down to one, but I think there is some leeway for cutting it down from > four. This definitely needs to be proposed to the anaconda devs, though. > I would be in favor of at least cutting it down from the current set. I think there's inherent value in the project saying "this is the layout we recommend" wen it comes to the guided path. It's not much of a guide to have four massively different partition schemes: one of which was a surprising new comer that didn't work at all up until beta and then imploded at the last second before ship. One of which at the time was still labeled experimental in the kernel, but that status wasn't revealed to the user, they had to go read tea leaves or visit the water cooler in the 5th floor stair well to know that. So I'd push for one and maybe we get two. *shrug* I'm well aware that suggesting greater conservatism on the guided path very well might mean Btrfs gets booted, even though I'd pick it as easier to learn and manage than LVM. > >> So really, I'm fairly convinced at this point that what's needed is >> feature chop, it's just a matter of how much which depends on what >> quality level expectations the WGs decide upon. > > What's your plan for moving forward with this? No plan. But I question whether WG members really understand the state of the installer: how many outcomes it enables; how many QA resources go into testing it as a percentage of all testing; and yet despite that, as a percentage of outcomes, how QA likely isn't testing even a majority of Manual partitioning outcomes; and the perception of Fedora users expecting that these outcomes have at least been attempted by QA. I think there's a disconnect. And I'm happy to be totally wrong about that, but when I look at other installers, I can't help but think they're successful not because of what they can do, but what they refuse to do. And yeah, we aren't going to ever have an installer that only produces 5 or 6 outcomes, it'll probably always be several dozen at a minimum. But several dozen right now would be an f'n godsend compared to what we've got. So I think the factual information of the installer state of affair, user perception and WG expectations for the installer need better qualification. Chris Murphy -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
