On Wed, 2019-08-28 at 15:59 -0600, Chris Murphy wrote: > > On one hand I understand all of the consternation around making btrfs bugs > > blockers for Fedora, but on the other hand it seems a bit silly to be having > > this conversation at all based on hitting a bug that went into the merge window > > and then was fixed before rc1 was even cut. Thanks, > > It is silly, if it's really safe to say that Btrfs won't be the > default file system in any release blocking deliverable. Having > blocker status was always a means to that end. But right now it's > maybe three (?) automated tests that depend on Btrfs working. If > Fedora Workstation defaulted to Btrfs, that's dozens or even hundreds > of tests? Adam? Well, yeah, but they all use the same filesystem layout. So either they all work or they're all broken, so far as any filesystem bug is concerned. But anyway, I've said this once already, but just to say it again: this discussion isn't happening because of any specific concern related to the bug that was linked in the original mail. The bug simply alerted the kernel team to the fact that we currently block on btrfs, which is something they thought we shouldn't do *anyway*. It's nothing to do with that particular bug at all. They just hadn't yelled about it before because, until an actual blocker bug showed up, they weren't aware of it. > And another question for QA. If it were Btrfs by default for > Workstation, would you just convert all the tests that rely only on > ext4 now to Btrfs? Or duplicate those tests so you can run them in > parallel? How much more testing is that and what's the impact on time > and resources? I mean, there wouldn't be any 'conversion'. That's just sort of not how the tests work. The tests work by running the installer and clicking stuff (talking about the openQA tests, here). If the default filesystem is different most of the tests will run the same - they'll just happen to be using a different default filesystem. I wouldn't duplicate all the tests and run them all on different filesystems, no, there isn't really much justification for that. We already theoretically block on about eight different filesystems, we don't re-run every single blocking test on each of those filesystems. If you start trying to do that kind of combinatorial testing you're going to blow up quite rapidly - do we do every single test on each blocking desktop on each blocking arch with each blocking filesystem on both BIOS and UEFI with three different graphics cards? By the time you multiply all those factors by each other you're probably already looking at several billion tests, and I haven't even thrown in another half-dozen factors I easily could throw in. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
