Criterion revision proposal: KDE default applications

[C. E. Kunkel]

On Tue, 2013-12-17 at 09:45 -0700, Chris Murphy wrote:
> On Dec 14, 2013, at 12:25 PM, Adam Williamson <awilliam at 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.