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