> > Idea #1: Do not block on optical media issues for Alpha and Beta releases
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> My concern here is that if we don't make it a blocker for at least beta
> but do for final, it's setting us up for a scramble at final time.
I understand the concern. However, is that really different from other Final-only criteria we already have, like Windows/macOS dual-boot (often broken due to grub/uefi), or "every tiniest app has to work" (surprises lurking everywhere)? Also, delaying Beta or delaying Final might end up as the same delay overall.
I think there are two things combined. The first one is blocking status. I'd like to have blocking status set exactly for that milestone which we believe it should block (and not an earlier one, just in case). The second thing is detection. We should be able to detect these issues early in the process, but we often don't, and we can talk about improvements here. I usually strive to avoid the situation where we test a Final test case for the first time only after Beta release (or with Final RC1). That's too late. If nothing blocks it, we should be able to test those e.g. with Alpha images. We don't have a good process designed there, and the missed test cases often come down to a lack of time, but if we improve that, I believe that would address your concern, right?
>
> > Idea #2: Do not block on optical media issues for Final release for
> > certain flavors/image types (Server, netinst)
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> +1 to this one. But is there likely to be a case where it fails on just
> those? I guess this primarily reduces what you need to _test_. So,
> yeah, +1.
As Adam described, we had cases where only certain type of images were affected, due to compose misconfiguration. So it's possible (even though not that likely nor frequent). That's why I'm interested more in tweaking guarantees that Fedora as a project claims to have ("image XYZ must be bootable from DVD or USB"), rather than test coverage optimization (that's internal to QA team, we can discuss that in our test list).
We can of course decide here that we want to keep our "must boot from optical media" guarantee for all iso images we produce, but reduce the testing to just one image from each type (Live, DVD, netinst). But that makes me feel somewhat uneasy, similar to what Adam said. That's why I'm mainly interested in talking about criteria adjustments first.
Since you're +1 here, do you have any opinion which release flavors/image types should be exempt from optical boot guarantee/criteria, and for which we should keep it? You have far a better overall idea of the project than I do.
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
