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
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.
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
This may be a dumb question, but why can't Redhat distribute NVIDIA binary
In NVIDIA's licence (http://www.nvidia.com/object/nv_swlicense.html) it
"2.1.2 Linux Exception. Notwithstanding the foregoing terms of Section
2.1.1, SOFTWARE designed exclusively for use on the Linux operating system
copied and redistributed, provided that the binary files thereof are not
modified in any
way (except for unzipping of compressed files)."
So, what's keeping RedHat from putting the drivers in the distribution? If
it's a GPL
thing, would it be easy to just download it during installation or at
least give the option to the user?
Ok, I have had Yarrow working well for a while now, but yesterday I
started experiencing some odd issues with my mouse. All of a sudden it
stops working correctly. The only thing that seems to fix is to kill X
and run mouse-test, then restart.
Also, I have FC 1 running on a desktop which is hooked up to a KVM
switch. Whenever I go to another PC, and return, the same thing
happens, the mouse goes crazy.
Hi folks! So the F35 retrospective has been up for a while:
I thought I'd send out my planned set of actions in response to the
points raised there. Please suggest any improvements you can think of.
I'll also put this on the agenda for the meeting on Monday, then I'll
go ahead and implement these (with any improvements that are suggested)
1. "adamwill - It took a long time to work through all the iterations
of the fedora-third-party/SELinux bug. Seems like we could have
tightened the loop on that somehow." - I don't think there's any
specific action to take immediately here, but if a similar situation
occurs in future I intend to be more hands-on about asking the relevant
component developers and the SELinux developers to work faster to get
to the bottom of the problem pile sooner.
2. "adamwill - Movement on the KDE blockers was initially slow, if we
could have resolved them earlier we would have had more time to find
and fix the bugs that eventually delayed Final." - I think we kinda
addressed this during the cycle, by pulling in some folks who were not
really involved in the blocker fix cycle previously. For F36 and later
we now have more KDE folks we can tap to get problems solved promptly.
3. "Ahmedalmeleh - Bugzilla is challenging to me and still getting used
to it. I wish I was able to learn how to operate OpenQA's automated
tests, in the given timeframe and was given guidance sooner.", also
Ahmed's 'wishlist' item and Matt's item - I'll plan to file a ticket
for improved guidance on using Bugzilla, and ask Ahmed for specific
input on what might help. I wonder if it might be a good idea to drag
ourselves into the 21st century and record some videos covering common
QA activities too, that might be something some folks would appreciate
more than text instructions? For openQA, I'll ask Ahmed for more detail
on specifically what he'd like to do with it here, as "operating" the
tests isn't something we envisage most contributors typically needing
4. "kparal - After F34, we talked in our team about doing a selected
compose testing in a complete full run (all test cases), way ahead of
the milestones (Beta and Final), and as a group effort to encourage
people to really fill out all test cases. Yet we never got to it in
F35. Some of the bugs might've been discovered earlier this way." - I
wonder if we could do this as a "test day" or "test week", or two:
schedule one event around Beta freeze and one event around Final
freeze, and have the goal of the event be to fill out the test
matrices. What do people think of this idea? If it seems like a good
one, I'll file tickets for creating those events.
5. "Mattdm - The timing of KDE Plasma releases is not well-aligned with
our schedule..." - this honestly doesn't seem like something QA can
really take action on, maybe it's more suited to the wider
retrospective Ben has been talking about?
6. "Mattdm - Lots of people (as non-scientifically measured by my
personal impressions of help requests I'm seeing) are hitting the
wireplumber-not-enabled problem. Maybe we should have blocked on that,
actually." - I've already updated the commonbugs note on this, but
another action we could take is to test upgrades from an older release
and see if we can spot the "pulseaudio still enabled" case happening
and if so what triggers it. Aside from that, I think we'll just have to
keep this one on record as an example to keep in mind when making these
kinds of subjective blocker calls in future.
7. "sumantrom - Sending some testing event updates to our "users" list.
I see surge in contributors when there is an article posted in Fedora
Magazine which means Fedora's user base wants to contribute/ try out
things. Posting things in the user-list will help." - this seems like a
good idea for sure. If we still work from an SOP for organizing these
kinds of events, a concrete action would be to add this step to the
SOP, I can file a ticket for that.
8. "sumantrom - Onboarding session on Bugzilla and test case writing."
- again this seems like a good idea, and we can file a ticket to have
such an event. Perhaps we could also link this up with point 3) and
record the session to use, perhaps after editing it down, as a "getting
started with Bugzilla" video?
9. "frantisekz - Some testing could have been conducted earlier in the
development, especially KDE/Discover blockers and bugs have been
present for a long time before the release." - I think the practical
step we can take here is already in progress: add more specific package
manager criteria and test cases. See the "new criterion proposal:
Graphical package managers" thread. Once the new criteria are decided,
we can create new test cases or extend existing ones, and once that's
done, the testing should get done more often and earlier. We can even
automate it. I can file tickets for those actions.
How does this sound to everyone? Please add any suggestions you have!
And there's still time to add new items to the retrospective itself, if
any new ones show up, I'll update this list of proposed actions.
IRC: adamw | Twitter: adamw_ha
During the F35 release cycle, there was a dissatisfaction that we use the
"basic functionality" criterion  too broadly when discussing package
manager issues (like multiple issues in plasma-discover). I was asked in
the latest QA meeting to propose a specific criterion to cover package
managers in detail. Here it is.
Please note that we already have package management partly covered in the
Basic criteria  and Beta criteria . Please read those first,
including footnotes. The following new criterion is proposed against the
The default graphical package manager for a given software type must
* install, remove and update software, even if multiple operations are
scheduled sequentially or concurrently
* list software installed on the system
* list available software (possibly in categories, a curated list, etc)
* display metadata relevant to the selected software (e.g. the description,
screenshots, the size)
* start the selected installed software
* configure software sources (enable/disable/add/remove repositories, set
default sources) and then adjust the available software pool accordingly
* notify the user when system updates are available (taking into account
the intended frequency of such notifications)
Note: Supported functionality and design decisions
All requirements apply only if such a functionality is supported by the
package manager; it does not imply that the package manager must support
all this functionality. The requirements don't apply if some functionality
is intentionally modified as a design decision (e.g. if some software
sources can't be disabled as an intentional precaution to users breaking
their system). If there is a bug violating the design decisions in one of
the covered areas (e.g. a software source which is supposed to be always
enabled can be disabled), it's up to the blocker review team to consider
whether this bug makes the user experience or system safety considerably
Note: Refer to Basic footnotes
The footnotes for the [similar Basic criterion covering console tools]
regarding software types, 'appropriate' behavior, scope and so on are all
generally applicable to this criterion also.
The criterion covers a lot of functionality. I'm coming from the notion
that the package manager (together with the web browser) is the most
important app on desktops, issues in it are very hard to work around for
users and provides core system functionality. That's why I think we should
have high standards for it.
Please let me hear your thoughts. Thanks.
Now that we've released F35, I'd like to share the first semi-annual
release retrospective survey:
I kept it intentionally short and open-ended. It should only take a
few moments of your time. If you have any questions, please let me
know. If you have suggestions for the next time around, there's a
field for that in the survey!
The survey is open through 4 December. I'll share results on the
Community Blog in late December or early January.
If you haven't seen, Adam is running a QA-specific retrospective as
well. If you only have QA feedback, you can record it on the wiki page
and I'll incorporate the responses into my final analysis.
He / Him / His
Fedora Program Manager