> > 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 -- [email protected]
To unsubscribe send an email to [email protected]
