On Mon, 2019-08-26 at 23:54 -0400, Neal Gompa wrote: > On Mon, Aug 26, 2019 at 7:16 AM <jkonecny@xxxxxxxxxx> wrote: > > On Sat, 2019-08-24 at 07:31 -0700, Adam Williamson wrote: > > > On Fri, 2019-08-23 at 19:00 -0600, Chris Murphy wrote: > > > > On Fri, Aug 23, 2019 at 1:17 PM Adam Williamson > > > > <adamwill@xxxxxxxxxxxxxxxxx> wrote: > > > > > > > > > So, there was recently a Thing where btrfs installs were > > > > > broken, > > > > > and > > > > > this got accepted as a release blocker: > > > > > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1733388 > > > > > > > > Summary: This bug was introduced and discovered in linux-next, > > > > it > > > > started to affect Fedora 5.3.0-rc0 kernels in openqa tests, > > > > patch > > > > appeared during rc1, and the patch was merged into 5.3.0-rc2. > > > > The > > > > bug > > > > resulted in a somewhat transient deadlock which caused installs > > > > to > > > > hang, but no corruption. The fix, 2 files changed, 12 > > > > insertions, 8 > > > > deletions (1/2 the insertions are comments). > > > > > > > > How remarkable or interesting is this bug? And in particular, > > > > exactly > > > > how much faster should it have been fixed in order to avoid > > > > worrying > > > > about it being a blocker bug? > > > > > > > > 7/25 14:27 utc bug patch was submitted to linux-btrfs@ > > > > 7/25 22:33 utc bug was first reported in Fedora bugzilla > > > > 7/26 19:20 utc I confirmed upstream's patch related to this bug > > > > with > > > > upstream and updated the Fedora bug > > > > 7/26 22:50 utc I confirmed it was merged into rc2, and updated > > > > the > > > > Fedora bug > > > > > > > > So in the context of status quo, where Btrfs is presented as an > > > > option > > > > in the installer and if there are bugs they Beta blocking, how > > > > could > > > > or should this have been fixed sooner? What about the handling > > > > should > > > > have been different? > > > > > > Nothing. The kernel team's concern is not related to this bug or > > > the > > > handling of this bug in any way. The only relevance of the bug is > > > that > > > it alerted the kernel team to the fact that we currently block on > > > btrfs, which they think we should not. > > > > I understand them. The point is, for them and even us (the > > installer) > > is work on BTRFS not a priority. It's something we can't benefit on > > RHEL and it could be almost completely replaced by LVM + xfs > > solution. > > However, it still giving us bugs and making our test surface > > bigger. > > > > > From the Anaconda team PoV it would make our lives easier to not > > support BTRFS at all. I'm not saying that we should drop BTRFS in > > Fedora, only that it would be easier for Anaconda team to be > > without > > that on Fedora. > > This is flat-out a trap. This is what makes Anaconda such a failure > as > a community project. Why does the past (RHEL) affect the present and > future (Fedora)? There's basically no way whatsoever to make anything > better with this logic. The Anaconda releases that any improvements > would be going into aren't even landing into the RHEL 8 branch that > governs the latest iteration of Fedora's past. From any reasonable > person's perspective, this answer makes no sense unless you're using > RHEL as an excuse to not support Fedora. > RHEL is not the past. Everything we do we have to think that it will go to RHEL and if it is Fedora specific we have to create a way to disable the functionality for another RHEL branching. And yes, we have a few things (not only a BTRFS) specific to Fedora the same way as a few things specific to RHEL which are disabled on Fedora. And as I wrote before, I'm not saying that we will remove the BTRFS support from Fedora. The point is that making the list specific to releases smaller will make our live easier. _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
