On Wed, 19 Feb 2014 21:59:54 -0700 Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: > > 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 concur with this reasoning. 80+ outcomes seems a little much - cutting some edge cases would be good. I don't know how wise it would be to 'sweep errors under the carpet' - The anaconda devs argument here is a sound one. Another question (and we should likely include the anaconda devs in this discussion) is if there's a way to catch errors, submit a bug report with the right information and then restart the installation inline (I realize this isn't a trivial addition - and might not be possible either). > 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. > The hard part, IMO, is figuring out what 'common configurations' should be included with the installer. I would imagine the answer to this is going to be different for each of the WG products. I wouldn't be surprised if going forward we end up with multiple installers (at some point down the line) - or multiple versions of anaconda. > > > > >> 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. > Even then, if we were able to trim the installation options to one or two options, those options aren't going to be the same across WGs. > > > > >> 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 Having this discussion now and getting some clarification is good. // Roshi
Attachment:
signature.asc
Description: PGP signature
-- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
