On Thu, 2012-10-11 at 01:15 -0500, Ian Pilcher wrote: > 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. Well, that's a complex question. =) As far as the release criteria would be concerned, yes. My thinking is that it's ultimately not exactly QA's decision what filesystem / device types anaconda ought to offer, which is sort of what we'd be doing by specifying particular types in the criteria, and it gets a bit unwieldy to specify every type we reckon is important or isn't. So in theory, sure, anaconda could drop RAID out of the interface and the proposed criterion would be satisfied. But that decision could be challenged _on its own merits_ rather than via the blocker process. I do see what you're saying though, like I said, I'm not sure I've got everything right here. It would be good to know what more people think about whether we should get into the business of specifying 'critical' partition / device types in the criteria or not. anaconda folks reading? > 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 ... I think we'd kinda have to establish that line as we went along, and maybe refine the criteria further. But do bear in mind this proposal affects only Beta as things stand. As noted below, the Final criterion would certainly cover such a configuration, as it's a 'workable partition layout'. So a failure of LVM-on-soft-RAID should be considered a final release blocker under the criteria as they stand. > > 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? Personally I'm not a huge fan of conditional things like this - 'X is a blocker if it worked in FN-1, but not if it didn't'. It seems like it could be a rabbit hole, too - I mean, what level of regression are we talking about exactly here? How do you define 'regression' when comparing newUI to oldUI? But i'm not saying no, just expressing current scepticism, do continue to argue me around =) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
