On Thu, Aug 27, 2020 at 8:37 PM Adam Williamson <adamwill@fedoraproject.org> wrote:

> > It must be possible to establish both IPv4 and IPv6 network connections
> > using DHCP and static addressing. The default network configuration
> > tools for the console and for release-blocking desktops must work well
> > enough to allow typical network connection configuration operations
> > without major workarounds.
>
>
> I'm a bit confused here. If you specifically say "for the console and for
> release-blocking desktops", does that mean it doesn't apply to the
> installer? Because at the top you say it applies to both, but here it
> sounds very specific.

No, I didn't intend that, I was just making sure to cover both console
and desktop. We can make it "for the console, for release-blocking
desktops and for installer environments" if you like.

I guess it would help to avoid the confusion.

> If it applies to the installer, does this mean that *all* ways to configure
> this in the installer must work (i.e. kernel cmdline, kickstart, gui, tui)?
> That seems quite demanding for a Basic criterion.

That's kind of a tricky one, because I agree it's broad, but on the
other hand there are situations where you kinda need each of them. You
can't always have a monitor and a human to do it interactively in the
install environment, and if you're retrieving a kickstart or the
installer environment itself (after a PXE boot, say) over the network,
you need the kernel cmdline case to work.

So, I mean, it's difficult. We *could* split it across Basic and Final,
but I can't immediately see a clear rationale for how to do that. Any
ideas? I guess we could look at what the criteria require for things
like kickstart and PXE boot and try to align them...

PXE is Beta, kickstart *delivery* is Beta. There are no further criteria related to kickstarts, I think I had I have an #action to propose that criterion that's a few years old now.

The "obvious" split would be to require user-related actions (gui/tui) sooner and professional-related actions later (kickstarts, cmdline). But at the same time, specifically for the installer, the professional-related actions are pretty important for QA to deliver a decent test coverage. Which coincidentally is also Beta ("Bug hinders execution of required Beta test plans or dramatically reduces test coverage"), but that doesn't feel right, if we truly want to aim for having Basic criteria valid all the time and applying Basic tests during package gating.

In the past, user actions took precedence over e.g. mass deployment features, because we tested manually first among local testers, and only then made public Alpha/Beta/Final releases for the mass audience. But with continuous testing through automation, the picture is reversed, and we need features like kickstarts and kernel cmdline options sooner than we need manual user actions.

So... I don't know, this is tricky :) Putting it all under Basic is of course ideal for us, and since there's still no meaningful difference between Basic and Beta, I guess it's good enough for now. Once there is some difference (like build gating rejection when these criteria are violated), the installer team might push for moving some of those requirements to a later stage.