criterion update: add "switch user" to Shutdown, reboot, logout
by Kamil Paral
Hello,
we're discussing a release criterion which is tightly related to GNOME and KDE environments. Could your teams please provide some feedback on the proposed criterion update, see below? Is user switching something you believe should be working (and in which milestone?), or should we rather de-emphasize/remove that function?
Please respond to the test@ list, if possible, to avoid fragmenting the discussion.
Thanks!
----- Original Message -----
> Hello,
>
> yesterday we have discussed whether user switching should be included in our
> criteria. We agreed that Beta is a good target for it, and accepted this bug
> as a blocker:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1184933
> https://bugzilla.gnome.org/show_bug.cgi?id=719418
>
> Now we need to adjust this criterion:
> https://fedoraproject.org/wiki/Fedora_22_Beta_Release_Criteria#Shutdown.2...
> Shutting down, logging out and rebooting must work using standard console
> commands and the mechanisms offered (if any) by all release-blocking
> desktops.
> Work? [hide]
> Similar to the Alpha criterion for shutting down, shutdown and reboot
> mechanisms must take storage volumes down cleanly and correctly request a
> shutdown or reboot from the system firmware. Logging out must return the
> user to the environment from which they logged in, working as expected.
>
> I propose this change:
> title: Shutdown, reboot, logout, switch
> Shutting down, rebooting, logging out and user switching must work using
> standard console commands and the mechanisms offered (if any) by all
> release-blocking desktops.
> Work? [hide]
> Similar to the Alpha criterion for shutting down, shutdown and reboot
> mechanisms must take storage volumes down cleanly and correctly request a
> shutdown or reboot from the system firmware. Logging out must return the
> user to the environment from which they logged in, working as expected. User
> switching must allow multiple users to perform live switching between their
> sessions, working as expected.
>
>
> What do you think?
8 years, 1 month
Webapps for developers
by Matthias Clasen
Hey,
we currently are shipping information for a relatively small set of
webapps so that they show up in gnome-software. Since we are aiming to
make the Workstation developer-focused, maybe we should add some
must-have developer sites to that list ? I'm really just asking for
suggestions here, I'm probably too old-fashioned in my development
habits to know the places that really should be on this list...
devdocs.io ?
stackexchange.com ?
github.com ?
8 years, 1 month
root password required for basic troubleshooting
by Chris Murphy
Hi,
In Fedora 20 and 21, the installer doesn't require setting the root
password. Yet systemd in both requires a root password to do anything,
including basic boot time troubleshooting, in both rescue.target and
emergency.target.
If the user is dropped to an emergency shell at boot, and are referred
to rdsosreport.txt, they can't do anything if they haven't set a root
password. And if they need to do a password reset, they're stuck also.
Questions
Is this the intended and desired UX for Workstation?
If not, what policy change is most practical? Requiring the user set a
root password, or somehow enabling systemd emergency.target to accept
a non-root user in group wheel?
Points of comparison
Windows has a burdensome password reset method, but it does offer
startup repair environments that don't require a password. OS X has a
safe boot option, as well as a separate recovery environment, also
without requiring a password, and a password reset can be done within
this environment.
--
Chris Murphy
8 years, 1 month
Evince browser plugin
by Michael Catanzaro
Hi,
I noticed the Evince browser plugin is not installed by default. It was
split into a subpackage to accommodate organizations that are concerned
about the security implications of displaying PDFs in the web browser,
and nothing installs the subpackage. This plugin is very good, and I
want it to be installed by default for all Epiphany users who have
Evince installed, as intended by upstream. (For Firefox users, it
doesn't matter because Firefox will use its own built-in PDF viewer in
preference to the plugin, Firefox makes it click-to-run which sucks,
and Firefox hangs when it dlopens a GTK+ 3 plugin anyway.)
The correct solution in most distros would be for the evince package to
have a Recommends for the evince-browser-plugin package, so that users
get it by default but sysadmins can decide not to install it if need
be. But we can't use Recommends yet. :S
So there are a few options I can think of:
* Add a Requires from evince to evince-browser-plugin, to be changed
into a Recommends once we're allowed to use those. This will sadden
those who do not want the browser plugin, but it's the most "correct"
approach.
* Add a Requires from epiphany-runtime to evince-browser-plugin. That
would make Epiphany depend on Evince, and we don't want apps to depend
on other apps, so this is my least favorite option. But it is
preferable to users having to discover and install the plugin
themselves. (It's a good plugin. :)
* Add evince-browser-plugin to the Fedora Workstation group in comps.
This is yucky since it only benefits Epiphany users, and Epiphany is
not installed by default. But I think it's preferable to a Requires
from Epiphany to Evince.
Any preferences or other suggestions? (If anyone can think of an option
that's actually good, that would be dandy.)
Michael
8 years, 1 month
rescue environment with live media
by Chris Murphy
Two problems with live media:
1. Installer team dislikes it because the environment gets
increasingly non-deterministic the longer the user uses the system
before installing the OS, and this can cause unpredictable installer
failures that are also quite difficult to test for. (This is an old
concern.)
2. The installer rescue mode isn't available with live media.
Both Ubuntu and openSUSE offer separate boot menu options for
installing the OS, vs booting the live environment. It seems both
problems above could be obviated if Fedora lives also distinguished
between installing vs booting live. I know this has come up before,
but not since products arrived.
It's understandable this is probably a Fedora 23 food for thought. It
is somewhat mitigated by the Fedora 22 plan to have separate product
netinstalls, with which the rescue mode will be available.
--
Chris Murphy
8 years, 1 month
Fedora 21 Alpha validation test work
by Adam Williamson
Hi, folks.
So, we're scheduled for Alpha TC1 tomorrow. We had a nice happy
co-operative plan where QA and the WGs would collaborate on revising the
release validation test process for Fedora.next...
...which, well, didn't really happen. As of this morning we were nowhere
near having a viable validation process. So I went for plan B: I spent
today more or less pulling the entire thing out of my ass.
It's a bit rough around the edges, but I think we more or less have
something workable now. I have skipped the draft stage for a lot of
documents just in the interest of having something vaguely workable in
time for TC1; of course, the pages can be revised as much as necessary
as we work with them.
It's a bit hard to remember everything I've done, but we now have a
draft Alpha Release Criteria page which should cover all
release-blocking media, which for now I'm assuming includes the
Workstation live media, Server minimal and offline install media, Cloud
and ARM disk images, and possibly some kind of generic network install
image. That draft is at
https://fedoraproject.org/wiki/User:Adamwill/Draft_F21_Alpha_criteria
and is based on the stuff from
https://fedoraproject.org/wiki/User:Adamwill/Draft_server_release_criteria , https://fedoraproject.org/wiki/User:Adamwill/Draft_workstation_release_cr... and https://fedoraproject.org/wiki/User:Roshi/QA/Cloud_Docs/Cloud_Alpha_Relea... , plus some adjustments to the templates that handle the preamble.
We have a new validation matrix, for Server product-specific tests:
https://fedoraproject.org/wiki/QA:Server_validation_results_template
The Desktop matrix has been adjusted to cover - not quite elegantly, but
at least cover - both the Workstation product and the KDE spin:
https://fedoraproject.org/wiki/QA:Desktop_validation_results_template
The Base matrix has been extended to add a couple of new test cases that
came out of the Product criteria drafting process, but actually aren't
really product specific, and has had its columns adjusted to be
product-y:
https://fedoraproject.org/wiki/QA:Base_validation_results_template
The installation matrix has similarly had a couple of new criteria
wedged in, but much more importantly, I ripped the netinst, DVD and live
image 'sanity test' sections and replaced them with an ARM-style table
where a single 'generic' test case is run against several images on
several platforms - that's the "Default boot and install" section, so
please cast an eye over it:
https://fedoraproject.org/wiki/QA:Fedora_21_Install_Results_Template
and I made a small change to the release validation test event SOP to
list the server matrix as one to create:
https://fedoraproject.org/wiki/QA/SOP_Release_Validation_Test_Event
Here are links to all (I think) of the new test cases I had to write as
I went along:
https://fedoraproject.org/wiki/QA:Testcase_Boot_default_install
https://fedoraproject.org/wiki/QA:Testcase_kickstart_user_creation
https://fedoraproject.org/wiki/QA:Testcase_base_service_manipulation
https://fedoraproject.org/wiki/QA:Testcase_base_selinux
https://fedoraproject.org/wiki/QA:Testcase_Server_firewall_default
https://fedoraproject.org/wiki/QA:Testcase_kickstart_firewall
https://fedoraproject.org/wiki/QA:Testcase_Server_cockpit_default
The following test cases already existed, but are newly included in the
release validation process (they were written for test days):
https://fedoraproject.org/wiki/QA:Testcase_FreeIPA_realmd_join
https://fedoraproject.org/wiki/QA:Testcase_realmd_join_kickstart
https://fedoraproject.org/wiki/QA:Testcase_realmd_join_server
There are still quite a few i's to dot and t's to cross. There are some
release criteria and test cases that explicitly reference 'the DVD'
image that will need to be adjusted. We need to apply the 'associated
release criterion' template to all the new test cases, and probably
clean up some categorizations. Various other process documentation pages
may need to be updated, we'll have to check through all of them. But I
think now we at least have the broad strokes of what's needed for .next
validation testing.
All feedback on the above changes is of course welcome! Please do cast
your eye over and point out anything I missed, anything that looks
silly, any possible improvements and so on. Remember, though, this is
really *test process* design: we're not actually doing product design
here, if you think there are issues with the Fedora.next changes
themselves, that goes to the WGs or FESCo. As far as this work is
concerned, we're just trying to test the new Products as they're
designed (all of the above is based off of the Product PRDs and tech
specs).
I'll take time tomorrow to do some polishing, and of course look at any
and all feedback on the stuff I did today.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
8 years, 2 months
Plan of Record for Fedora 22 Network Install Media
by Stephen Gallagher
(Cross-posted to the WG mailing lists; please reply only to devel@)
== Overview ==
Today in #anaconda, we had a discussion of the plans for network install
media for Fedora 22. We acknowledged that the network install (and more
generally, unattended installation) story in Fedora 21 was somewhat
lacking. In particular, there was user confusion around how to deploy
Fedora Workstation in an unattended manner.
Some of the problems we faced in Fedora 21 were a result of not having
necessary plumbing in Anaconda (largely because we didn't even realize
this until well into Beta phase, at which point we just started breaking
out the duct tape and chewing gum). In particular, we needed a way for
individual Fedora editions to provide a mechanism for specifying
different defaults (such as automatic partitioning rules or the default
environment group that would be displayed in an attended install).
Without these things, while we could produce media with separate
graphical branding, we couldn't truly produce separate network installs
for Cloud, Server and Workstation. So we settled on producing only the
Server network install media.
== Output ==
In Fedora 22, we will be producing four network install ISOs:
* Fedora Server
- Server branding
- Default environment group: Fedora Server
- Auto-partitioning defaults: LVM on XFS (except /boot)
- Responsible WG: Server WG
* Fedora Workstation
- Workstation branding
- Default environment group: Fedora Workstation
- Auto-partitioning defaults: LVM on EXT4
- Responsible WG: Workstation WG
* Fedora Cloud
- Cloud branding
- Default environment group: Fedora Cloud
- Auto-partitioning defaults: TBD
- Responsible WG: Cloud WG
* Fedora "Generic" (name TBD)
- Generic Fedora branding
- Default environment group: minimal
- Auto-partitioning defaults: TBD
- Responsible WG: Base WG
In addition, there is ongoing discussion around media for bare-metal
Fedora Atomic installations. This has not been finalized, but will
likely result in an additional output.
While each of these network installs will be *capable* of also
installing any of the other products (though possibly not with the
expected auto-paritioning), we have agreed that QA testing will only be
performed on the intended environment group target for the branded
media. We will not advertise or make any special effort to support other
targets.
== Remaining work that needs to be done ==
Release engineering will need to modify their compose tools to produce
each of these install trees, as well as handling the necessary mirroring
functions.
The working groups responsible for each of these install media will be
responsible for performing the following tasks before the Alpha Freeze
(ideally well before, so we can run test composes and fix issues without
slipping):
* Modify the appropriate fedora-productimg-$PRODUCT package to include
an anaconda extension model that will extend the InstallClass and set
the default environment group and optionally modify the
auto-partitioning functionality.
* Review the contents of comps-f22.xml.in and the related kickstart
files in spin-kickstarts to ensure that the install media contains the
appropriate content.
For simplicity in understanding who to contact, it would be beneficial
if each of the responsible working groups would nominate an individual
to be the point of contact on these changes. I volunteer myself to
represent the Server WG in this capacity.
Given that we branch on February 10th enter Alpha Freeze on February
24th, I'd like to propose a soft deadline (a check-in) on February 9th
with a hard deadline on February 16th in order to have time to run at
least one test compose prior to Alpha Freeze.
== Acknowledgements ==
The cast of characters involved in this discussion were:
* Stephen Gallagher (Server WG)
* Dennis Gilmore (Release Engineering)
* Brian C. Lane (Anaconda)
* Ian McLeod (Project Atomic)
* David Shea (Anaconda)
* Adam Williamson (QA)
8 years, 2 months
