Hi folks!
So at this week's blocker review meeting, the fact that we don't have
explicit networking requirements in the release criteria really started
to bite us. In the past we have squeezed networking-related issues in
under other criteria, but for some issues that's really difficult,
notably VPN issues. So, we agreed we should draft some explicit
networking criteria.
This turns out to be a big area and quite hard to cover (who'd've
thought!), but here is at least a first draft for us to start from. My
proposal would be to add this to the Basic criteria. I have left out
some wikitext stuff from the proposal for clarity; I'd add it back in
on actually applying the proposed changes. It's just formatting stuff,
nothing that'd change the meaning. Anyone have thoughts, complaints,
alternative approaches, supplements? Thanks!
=== Network requirements ===
Each of these requirements apply to both installer and installed system
environments. For any given installer environment, the 'default network
configuration tools' are considered to be those the installer documents
as supported ways to configure networking (e.g. for anaconda-based
environments, configuration via kernel command line options, a
kickstart, or interactively in anaconda itself are included).
==== Basic networking ====
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. Standard network functions such as address
resolution and connections with common protocols such as ping, HTTP and
ssh must work as expected.
Footnote titled "Supported hardware": Supported network hardware is
hardware for which the Fedora kernel includes drivers and, where
necessary, for which a firmware package is available. If support for a
commonly-used piece or type of network hardware that would usually be
present is omitted, that may constitute a violation of this criterion,
after consideration of the [[Blocker_Bug_FAQ|hardware-dependent-
issues|normal factors for hardware-dependent issues]]. Similarly,
violations of this criteria that are hardware or configuration
dependent are, as usual, subject to consideration of those factors when
determining whether they are release-blocking
==== VPN connections ====
Using the default network configuration tools for the console and for
release-blocking desktops, it must be possible to establish a working
connection to common OpenVPN, openconnect-supported and vpnc-supported
VNC servers with typical configurations.
Footnote title "Supported servers and configurations": As there are
many different VPN server applications and configurations, blocker
reviewers must use their best judgment in determining whether
violations of this criterion are likely to be encountered commonly
enough to block a release, and if so, at which milestone. As a general
principle, the more people are likely to use affected servers and the
less complicated the configuration required to hit the bug, the more
likely it is to be a blocker.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
==============================================
#fedora-meeting-2: Workstation WG (2021-04-27)
==============================================
Meeting started by cmurf at 22:34:44 UTC. The full logs are available at
https://meetbot.fedoraproject.org/fedora-meeting-2/2021-04-28/workstation.2…
.
Meeting summary
---------------
* Rollcall (cmurf, 22:34:58)
* present: Allan, Chris, Tomas, Michael, Neal, Matthias, Kalev, Jens,
Owen (cmurf, 22:34:59)
* regrets: Langdon (cmurf, 22:35:01)
* present guests: (cmurf, 22:35:03)
* Approval of April 20 minutes (cmurf, 22:35:05)
* LINK:
https://meetbot.fedoraproject.org/fedora-meeting-2/2021-04-21/workstation.2…
(cmurf, 22:35:07)
* AGREED: no objections, approved (cmurf, 22:35:09)
* Announcements and Status reports (cmurf, 22:35:11)
* Fedora Linux 34 released! (cmurf, 22:35:13)
* Allan has been working on F34 Workstation article (cmurf, 22:35:15)
* Matthias contacted Matthew Miller to come next week (cmurf,
22:35:19)
* Elect WG chair for F35 release cycle (cmurf, 22:35:21)
* Neal wins by default by lack of other candidates (cmurf, 22:35:23)
* Michael is vice-chair now (cmurf, 22:35:25)
* Open Floor (cmurf, 22:35:27)
Meeting ended at 22:35:38 UTC.
Action Items
------------
Action Items, by person
-----------------------
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* cmurf (20)
* zodbot (7)
* mcatanzaro (0)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
Hi Fedora users, developers, and friends!
It's time to start thinking about Test Days for Fedora 35.
For anyone who isn't aware, a Test Day is an event usually focused
around IRC for interaction and a Wiki page for instructions and results,
with the aim being to get a bunch of interested users and developers
together to test a specific feature or area of the distribution. You can
run a Test Day on just about anything for which it would be useful to do
some fairly focused testing in 'real time' with a group of testers; it
doesn't have to be code, for instance, we often run Test Days for
l10n/i18n topics. For more information on Test Days, see
https://fedoraproject.org/wiki/QA/Test_Days .
Anyone who wants to can host their own Test Day, or you can request that
the QA group helps you out with organization or any combination of the
two. To propose a Test Day, just file a ticket in fedora-qa pagure - here's
an example https://pagure.io/fedora-qa/issue/624 . For
instructions on hosting a Test Day, see
https://fedoraproject.org/wiki/QA/SOP_Test_Day_management .
You can see the schedule at
https://pagure.io/fedora-qa/issues?tags=test+days .
There are many slots open right now. Consider the development
schedule, though, in deciding when you want to run your Test Day - for
some topics you may want to avoid
the time before the Beta release or the time after the feature freeze
or the Final Freeze.
We normally aim to schedule Test Days on Thursdays; however, if you want
to run a series of related Test Days, it's often a good idea to do
something like Tuesday / Wednesday / Thursday of the same week (this is
how we usually run the X Test Week, for instance). If all the Thursday
slots fill up but more people want to run Test Days, we will open up
Tuesday slots as overflows. And finally, if you really want to run a
Test Day in a specific time frame due to the development schedule, but
the Thursday slot for that week is full, we can add a slot on another
day. We're flexible! Just put in your ticket the date or time frame you'd
like, and we'll figure it out from there.
If you don't want to run your own Test Day, but you are willing to
help with another, feel free to join one or more of already accepted
Test Days:
GNOME Test Day*
i18n Test Day*
Kernel Test Week(s)*
Upgrade Test Day*
IoT Test Week*
Cloud Test Day*
Fedora CoreOS Test Week*
And don't be afraid, there are a lot of more slots available for your
own Test Day!
[*] These are the test days we run generally to make sure everything
is working fine, the dates get announced as we move into the release
cycle.
If you have any questions about the Test Day process, please don't
hesitate to contact me or any member of the Fedora QA team on test at
lists.fedoraproject.org or in #fedora-qa on IRC. Thanks!
--
//sumantro
Fedora QE
TRIED AND PERSONALLY TESTED, ERGO TRUSTED
On Thu, 2021-04-22 at 03:00 +0000, rawhide(a)fedoraproject.org wrote:
> According to the schedule [1], Fedora 34 Candidate RC-1.1 is now
> available for testing. Please help us complete all the validation
> testing! For more information on release validation testing, see:
> https://fedoraproject.org/wiki/QA:Release_validation_test_plan
Hey folks! This is the real-deal first RC for F34 Final, with all known
blockers fixed. We only have a short time before the go/no-go meeting,
but I am going to see if we can push that to Friday without impacting
the schedule. In the meantime, please do help test it as much as
possible. Thanks!
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
Hi,
I'd like to do a shorter Workstation meeting next week to allow some
time for people to attend Red Hat Summit [1] if desired. Instead of
meeting from 9:30-10:20 AM EDT as usual, let's instead go from
9:30-9:55 AM EDT to avoid clashing with Summit. This will be a good
meeting to handle small things, not a good time to attempt to tackle
grand issues. In particular, I think we can nominate a chairperson for
the F35 release cycle at the next meeting. If that's all we need to
discuss next week, we might finish even earlier. Feel free to tag small
issues with meeting-request as usual.
You might notice I'm trying to follow Google Calendar's short meetings
rule: 50 minute meetings in an hourlong timeslot, and 25 minute
meetings in a half hour slot. Hopefully this makes the end of the
meetings less stressful. ;)
Michael
[1] https://www.redhat.com/en/summit