On Tue, 2013-12-17 at 09:45 -0700, Chris Murphy wrote: > On Dec 14, 2013, at 12:25 PM, Adam Williamson <awill...@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. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
