On 10/11/2012 12:31 AM, Adam Williamson wrote: > We agreed at the blocker review meeting this morning that "most > commonly-used filesystem types" was really pretty vague and > unsatisfactory. The specific case we were considering was LVM. In the > end we agreed that, really, at Beta stage, anaconda ought to be capable > of dealing with any filesystem / device type it offers (the 'device > types' are LVM, RAID and btrfs). If a type isn't working it needs to be > either fixed or suppressed (as we did for the last couple of oldui > releases with btrfs - we suppressed it from the list as it wasn't > working). The intent here isn't to cover every possible bizarre > permutation anyone can come up with (the Final criterion does do that), > but more that just simply creating a partition in a pretty normal, > everyday way with any of the options offered shouldn't cause the > installer to fall over and die. Please, anaconda folks, if you think > this is too optimistic and you think we should exclude specific types or > limit the criterion to a specific subset of types, yell. Am I interpreting this correctly to mean that a beta can go out without support for software RAID and/or LVM, as long as they are not offered in the Anaconda interface? If so, uugh. Also if the intent isn't to support "every bizarre permutation", what combinations are required to work (if any)? My specific concern is LVM on top of software RAID. I've been running said configuration since at least RHL 8, and I'm getting pretty tired of having Anaconda break on it every 2 or 3 releases. I try to do my part by testing, but ... > It's worth noting that we're still using the old 'The installer must be > able to create and install to any workable partition layout using any > file system offered in a default installer configuration, LVM, software, > hardware or BIOS RAID, or combination of the above' criterion for Final. > I think this is not entirely optimal; the scenario dcantrell proposed in > the 'criteria review' thread, for instance, would technically be covered > by this. But revising it would be very difficult, I think, because all > you can really do is either write a *giant* laundry list of use cases in > the 'custom partitioning should be capable of' format, which is ugly and > horribly non-scalable, or wave a white flag and say 'partitioning issues > are subjective and we'll just deal with them case-by-case'. Those are > the only options I can come up with, anyway. If anyone has a neat idea > for improving the final criterion, please do propose it, because I'm > damned if I can. :) Could we at least have a no regressions criterion? -- ======================================================================== Ian Pilcher arequipeno@xxxxxxxxx "Sometimes there's nothing left to do but crash and burn, or die trying" ======================================================================== -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
