On Thu, Mar 26, 2015 at 5:32 PM, Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx> wrote: > On Thu, 2015-03-26 at 15:35 -0600, Chris Murphy wrote: >> >> Proposal is to submit them to FESCo to a.) acknowledge they're >> blockers; > > I don't see any need for FESCo to do that. We have a process for > deciding whether bugs are blockers. If what you really want is a FESCo- > shaped stick to wave at developers, I'm not sure that's really going > to *help* anything. The process for the grubby bug has resulted in three different determinations. It's come up for review more times than I want to count, and is up for review yet again (twice just in this cycle). My motivation here is strictly to arrive at a definitive determination and stick to it, so QA doesn't ever have to see this bug again. >> b.) grant an exception for blocking Fedora 22 on the basis >> that they're not crazy showstoppers for many people yet; and c.) >> should be tagged as blockers for Fedora 23, and as such there are no >> excuses for them not getting fixed by then. > > Again I don't see any reason to invoke FESCo to do any of that. If we > wanted to do that, it's perfectly fine to do so through the usual > blocker review processes and the teams involved, by policy, in those. If there's a way for QA to state a bug is a blocker, but will block the next Fedora rather than the current one, that's news to me. If so, great, I suggest doing that. Get them both off the Fedora 22 plate. The motivation for postponing 1185117 to Fedora 23 is because I suspect fixing it involves non-trivial UI consideration to make it possible to delete pools. If you want me to ask anaconda if they concur, I will. And if you want me to just drop this thread's premises/conclusion entirely, fine too. On Thu, Mar 26, 2015 at 5:33 PM, Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx> wrote: > On Thu, 2015-03-26 at 15:35 -0600, Chris Murphy wrote: >> Why? Process. I think it's better to adhere to process, and thus far >> there's a rather obvious resistance to fixing these two bugs in the >> Fedora 22 time frame. So here's an alternative approach. > > I'll note that we've never violated process in relation to 864198, > AFAICS. Each time it's come up, the resolution has been to disallow > /boot on btrfs. So far as the blocker process is concerned, that's a > perfectly valid approach to making the bug not a blocker. Release criteria as currently written, the installer must "Create mount points backed by ... btrfs volumes", and /boot is a mount point, therefore the above approach, while completely sane, is certainly a gray area. If this same bug applied to XFS would it be treated the same? Ext4? -- Chris Murphy -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
