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

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



On Thu, Mar 3, 2016 at 1:29 PM, Adam Williamson <awilliam redhat com> 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 redhat com> 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


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