On Thu, Mar 26, 2015 at 5:32 PM, Adam Williamson
<adamwill(a)fedoraproject.org> 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(a)fedoraproject.org> 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