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. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@xxxxxxxxxxxxxxxxxxxxxxx
