On Thu, Mar 3, 2016 at 1:29 PM, Adam Williamson <awilliam@xxxxxxxxxx> wrote: >> 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. > > We discussed it in this very thread, the reasoning is available in > dlehman's earlier posts to it. Personally I think his position is > entirely reasonable. What/where? I've addressed the ridicule and scapegoating already, the only other one I'm seeing is a strawman argument: On Wed, Feb 24, 2016 at 7:40 AM, David Lehman <dlehman@xxxxxxxxxx> wrote: "What is the appropriate tool (and parameters) for resizing the formatting on a device with unrecognized/unknown formatting?" Comment 33c. "The tool doesn't exist." No one is asking anaconda-blivet to perform magic by successfully resizing devices with unknown contents, so the question David's asking is an obvious fallacy. >From the original bug description (1st post): Expected results: Should be listed as "not resizeable" > > The blocker process is not one where "QA make[s] the bug a blocker". > The blocker process, as designed, is a collaboration between QA, devel, > releng, and product management (FPL and FPM). Note the inclusion of > devel there. The criteria were initially written in close collaboration > with the development teams, and are frequently adjusted to reflect > their conception of what's practical and reasonable, and development > teams absolutely are expected and intended to have input into the > blocker 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 > > I'm not quite sure what you're suggesting here; are you suggesting that > we could have rejected it as a blocker on the basis that it's a > conditional violation of the criterion and we declare that the impact > is not broad enough? Yes. >We could have done that, sure, but in the end we > went a different way as we wanted to clarify the question of whether > the criterion was intended to dictate anaconda's behaviour with regard > to unknown partitions. And you did clarify it: Unintended data loss of user valued data in guided partitioning, where many prognostications where made by Anaconda folks how data safe it is designed to be, is possible. And yet no matter how many more people hit it, it would not be considered a blocker. It's a bad bug in custom partitioning, it's an egregious bug in guided partitioning. In my opinion you've pretty much only listened to David's circular argumentation, and haven't incorporated anything that takes the user into account. You really think it's OK for this to never be a blocker no matter how many more get hit by it? -- Chris Murphy _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
