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

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



On Wed, 2016-03-02 at 22:28 -0700, Chris Murphy wrote:

> 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:

This tone is really not warranted. We agreed the bug would have
violated the criterion as written, but we also observed that this isn't
a situation that was actually envisaged when writing the criterion; the
criterion was written thinking about the case where anaconda
incorrectly tried to resize a partition it understood, it was not
intended to prescribe anaconda's behaviour with regard to partitions it
does not understand. I can tell you that, as I wrote it.

> 
> 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

The quote out of context is maybe misleading, and I think quoting it at
two removes (from #anaconda IRC to the blocker meeting to here) is a
little unfair. I believe that, in context, dlehman was referring to the
idea of "fixing" detection of Apple Core partitions, not the
possibility of tightening down on resize of unknown partitions.

> 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.

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? 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.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net



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