On Wed, 19 Feb 2014 21:59:54 -0700
Chris Murphy <lists(a)colorremedies.com> wrote:
On Feb 19, 2014, at 6:07 PM, Adam Williamson <awilliam(a)redhat.com>
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