On Thu, Aug 27, 2020 at 8:37 PM Adam Williamson <adamw...@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.
_______________________________________________
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
