On Thu, 2015-06-25 at 18:06 -0600, Chris Murphy wrote: > On Thu, Jun 25, 2015 at 1:29 PM, Adam Williamson > <adamwill@xxxxxxxxxxxxxxxxx> wrote: > > On Wed, 2015-06-24 at 14:49 -0600, Chris Murphy wrote: > > > On Wed, Jun 24, 2015 at 2:42 PM, Chris Murphy < > > > lists@xxxxxxxxxxxxxxxxx> wrote: > > > > Yet this bug [1] is routinely voted > > > > > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=864198 Not that > > > anyone should go try to make sense out of a three year old bug > > > with > > > over 100 comments... but the gist is "nah, we don't want to fix > > > it > > > now, therefore the release criteria don't matter". > > > > That is not an accurate summary. For F20 it was rejected as a Beta > > blocker and accepted as a Final blocker. It was addressed by > > preventing > > the installer from allowing /boot to be on a btrfs subvolume. > > Preventing the conditions that result in boot failure is not the same > thing as fixing the underlying problem with /boot on Btrfs being > unsupported by grubby. Indeed it isn't, but I never said it was. I said your characterization of how the release criteria have been applied was incorrect, and I stand by that. > And since something like > Fedora 18/19 we supposedly agreed Btrfs should have parity with other > fs's with respect to release criteria, but plainly that's not the > case. I don't recall that, do you have any references? If anything we may have said it should get more prominence *on the basis it would soon be the default FS*, but that basis clearly hasn't worked out in reality. (FWIW, I'd apply the same principles to a similar bug in any FS which is not the default for any of our release-blocking flavors.) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
