rfc: expectations for partitioning, Fedora.next

[Mike Ruckman]

On Wed, 19 Feb 2014 21:59:54 -0700
Chris Murphy <lists at colorremedies.com> wrote:

> 
> On Feb 19, 2014, at 6:07 PM, Adam Williamson <awilliam at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/test/attachments/20140221/cbdc3879/attachment.sig>