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 _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
