On Tue, 2013-12-17 at 09:45 -0700, Chris Murphy wrote:
On Dec 14, 2013, at 12:25 PM, Adam Williamson
<awilliam(a)redhat.com> wrote:
>
> I really would like to see other people's proposals in this area. I'm
> not at all convinced I'm going to be the person who comes up with the
> best idea. I'd love to know what cmurf would suggest as an overall
> approach to designing a set of Final release criteria or a storage
> validation test plan, for instance.
What do you think of moving any blocking storage related criteria and tests, from final
to beta or even alpha? Why not move as much potential for blockers to alpha and beta
releases as possible?
An example of this is moving resize test and criterion to beta (or split between alpha
and beta if that's sensible and helpful). If resize were busted, do we really only
want to find out and start dealing with it, and maybe slipping on it, during final? Seems
risky, especially if a fix depends on upstream developers. Or public beta eats OS X or
Windows for lunch.
Since alpha and beta blocking criteria are still in effect post-beta, there will still be
storage related blocking bugs after beta release. But there wouldn't be new blockers
based on additional criteria. Rather than increasing the quality of beta, the main idea is
to increase the predictability of final and reduce risk of regressions and final release
slip.
I think guided partitioning should be fairly rock solid, and even though it's the
"simple" path, it's still a beast of a matrix. I mentioned this in a
different thread, but I think either LVM or LVM Thin Provisioning needs to be demoted. We
don't need two LVM options in Guided. And if we can't get buy off on that, then
we'll have to just eat that extra testing, because I think Guided shouldn't get
people into trouble.
Custom partitioning needs to be triaged for certain use cases we really want to work, and
make those blocking if they fail. It may not be the same list for i386, x86_64/EFI, and
ARM. e.g. we supposedly block on raid5 for x86_64, but does that make sense for ARM? Other
combinations, even if there's a crash, would be non-blocking bugs, and only the
subjective FE determination applies.
Obviously the data corruption proscription is still in place, so crashes that lead to
mangled partition tables or previously working file systems, presumably would block.
However, I wonder if that criterion should be split in two: clearly not OK block worthy
cases probably ought to be an alpha or beta blocker at the latest; and those that are
suitable for FE or merely being documented could be permitted post-beta since they're
unlikely to block.
Chris Murphy
+1. Move as much as makes sense in the storage testing to as early as
possible.