On Mon, Feb 29, 2016 at 7:29 AM, David Lehman <dlehman@xxxxxxxxxx> 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 saying: 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 https://meetbot.fedoraproject.org/fedora-blocker-review/2016-02-22/f24-blocker-review.2016-02-22-17.00.log.html 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. https://fedoraproject.org/wiki/Blocker_Bug_FAQ -- Chris Murphy _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
