1.
/boot on Btrfs grubby (83 comment, 2.5+ year, booger we can't flick off) https://bugzilla.redhat.com/show_bug.cgi?id=864198
The first one is fairly appalling because it's a.) old, b.) there's a tested patch, c.) we're in contempt of our own lament for contributors when b and c and it still doesn't get fixed; and d.) Josef openly called for replacing grubby with something that works, seeing as openSUSE, Ubuntu, Debian, (does anyone else?) don't have this problem.
2.
Custom partitioning does not allow convenient removal of volume including snapshots (btrfs, LVM) https://bugzilla.redhat.com/show_bug.cgi?id=1185117
This might seem like it snuck up on us, but I predicted it would become a problem in two different RFEs one of which is ~18 months old. [1] Neverthless, openSUSE's default highly snapshottycentric behavior enhances this problem; but so does Docker on Btrfs; and now in systemd-219 it's using Btrfs snapshots for container cloning. So these things are going to continue coming out of our ears.
PROPOSAL:
QA doesn't have an exception policy. If a bug is a blocker under the current criteria, they block release. Done.
Proposal is to submit them to FESCo to a.) acknowledge they're blockers; 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.
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.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1015657 https://bugzilla.redhat.com/show_bug.cgi?id=1022316
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.
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.
On Thu, Mar 26, 2015 at 5:32 PM, Adam Williamson adamwill@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@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?
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.
On Thu, 2015-03-26 at 15:35 -0600, Chris Murphy wrote:
Custom partitioning does not allow convenient removal of volume including snapshots (btrfs, LVM) https://bugzilla.redhat.com/show_bug.cgi?id=1185117
This might seem like it snuck up on us, but I predicted it would become a problem in two different RFEs one of which is ~18 months old. [1] Neverthless, openSUSE's default highly snapshottycentric behavior enhances this problem; but so does Docker on Btrfs; and now in systemd-219 it's using Btrfs snapshots for container cloning. So these things are going to continue coming out of our ears.
So anaconda team got in touch and said they don't believe this should be a blocker and would like it to be re-considered: https://bugzilla.redhat.com/show_bug.cgi?id=1185117#c17
I'm therefore dropping the AcceptedBlocker tag which makes it back into a proposed blocker.
We can wait for the next blocker meeting to re-consider it, or come to a consensus here.
I think Chris makes a good case that it's a significant issue, but on the other hand, anaconda devs make a fair point that this isn't exactly a 'bug', but a case where anaconda's current design and implementation doesn't work well; 'fixing' it isn't a simple case of 'make this code do what it's supposed to do', but 'come up with and implement a design with a new capability', it's new engineering, it's not bug fixing.
There are ways to deal with the issue; remove the volume using another tool before running anaconda, do it from a console while anaconda is running.
The criterion involved here says the installer must be "able" to "Remove existing storage volumes", including LVM and btrfs volumes. Removing all the snapshot volumes is possible - tedious, but possible.
So personally I'm OK with the bug not being a release blocker. Other opinions?