[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Blocker status of RHBZ #1033778 (shrinking unknown volumes)

On Mon, Feb 29, 2016 at 7:29 AM, David Lehman <dlehman redhat com> wrote:

> It is not possible to distinguish between a lack of meaningful data and
> meaningful data that the OS has no means of recognizing. A partition
> type flag or GUID is not generally sufficient for this purpose.

You're effectively asserting the validity of ignoring partition type
GUIDs as if this is free space, or an invalid/stale partition type,
whenever you don't recognize the contents or GUID. This is folly. e.g.
Chromium OS puts binary blobs in partitions with no filesystems at
all, depending only on partition type GUID for identification.
Anaconda sees 21 of 28 Chromium OS partitions as resizable, doing so
will of course break them.

OS X and Windows tools don't let users shrink partitions with
unrecognized contents. Ubuntu and openSUSE installer-partitioners also
don't permit it. Anaconda is manifestly more dangerous, in the same
situation. This situation disproportionately affects OS X users
because the OS X default on disk layout is affected by this bug now
for just over a year so I expect more users will be affected.

I've evaluated five installer-partitioners for comparison with respect
to this bug. How many have you evaluated? Can you point to any others
that offer resize UI for partitions with unrecognized contents? If so
and it's free software I will promptly go file a bug for that product
too, because it's a flawed design that sets the user up for failure.

> We do have the option to prevent resize of devices with no formatting
> or unrecognized formatting. You could certainly argue that it makes
> more sense to remove such a device than to resize it if you need more
> space.

David, that's what I've been saying for two years in the bug report,
while you've been consistently blaming the user for running into it.

>I'll just explain that it's in the name of protecting careless
> users when the bugs start coming in.

Unconvincing.  You know more about storage esoterics, and you know
about this data loss bug, the user doesn't. You've been using the
appeal to ridicule and scapegoating logical fallacies from day 1,
directed at the user and in the jab at Karel Zak. Fallacies might work
for some people until you get caught and they see that you have no
actual good arguments, so consider yourself caught. Blaming and
mocking the user and another developer, both of whom have had no say
in this design or consequential behavior, are not compelling reasons
to invalidate bug or its status as a blocker bug.

For 10+ years, resize in a GUI partitioner has been considered by
users to be safe, and not only because resize UI isn't offered when it
can't be done safely. Ask a file system developer (I've asked a few)
and they expect filesystem resize to be a fail safe operation. It
might fail, but there should be no data loss. If there is, it's a
major bug, they'd freak out and fix it.

On the one hand you admit things could be handled better, but then you
resort to yet more backhanded blame and mockery in the very same bug
post. That's a big part of what gets my goat about this bug, it should
have long ago been an ordinary "oops, not good, we should probably fix
that in the next release or two" kind of bug. Bugs happen. Bad bugs
happen. Blaming others for this bug isn't indicated.

As for whether it's a blocker bug:  In three blocker meetings everyone
was prepared to make it a blocker on the merits of the bug. My
educated guess is no one wanted to fight with you about it when you
dole out derision like Kleenex, and also added further duress by

18:38:23 <adamw> <dlehman> lol
18:38:23 <adamw> <dlehman> I might go so far as to get myself kicked
out of the fedora project before "fixing" that

This is untenable for QA to make the bug a blocker when the upstream
announces in advance they won't fix it. How does that play out? Your
(circular) logic here is, it's not a blocker because you say it's not
a blocker. You've simply bugged out of participating in a neutral 3rd
party process established to arrive at a minimum quality releasable
product. QA folks went with the pragmatic path of least resistance,
didn't they? I see no where that they agreed with your reasoning,
because you didn't provide any reasoning.

How many more users need to hit this bug before you'd fix it inside of
two minutes? I'd be willing to bet one or maybe two more. I seriously
doubt you really believe this is never a blocker even if 10 OS X users
get impaled by it. And yes it's completely reasonable that everyone
has more important and interesting things to do than fix this bug,
that applies to a lot of bugs and even sometimes blockers, but that's
the process.

This sounds pretty close to perfect as a conditional blocker, a.k.a.
it's a "local configuration dependent issue" since it mainly affects
OS X users with the default partitioning layout now in use on that OS,
and then the user proceeds with resizing this unknown partition for
whatever reason. Fix it whenever you want. Maybe someone beats you to
it. And consider trusting QA to make it a blocker at some point if
more users hit it. I don't really see a problem with that method of
making it not an immediate blocker for this release.

Chris Murphy

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]