> > 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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Reply via email to