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, 8 months
Workstation WG panel at DevConf.cz
by Paul W. Frields
I'd like to submit a WG panel talk to the DevConf.cz conference. The
panel would consist of Workstation WG members in attendance. We can
use this session to talk about progress and plans on later iterations
of the Workstation "flavor" of Fedora.
http://devconf.cz
I see this panel as a useful way to also connect the dots between
what's happening in GNOME upstream, where Fedora and FOSS developers
can help, and so on. I'd provide some seed questions for the panel,
and also we would invite questions from the audience.
At least Christian Schaller and I will be there; how many others plan
to attend?
--
Paul W. Frields http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://redhat.com/ - - - - http://pfrields.fedorapeople.org/
The open source story continues to grow: http://opensource.com
8 years, 10 months
High contrast icons blocking Fedora releases - do we really want to?
by Adam Williamson
Hi, folks. So something came up in passing at the QA meeting today which
we agreed to discuss here.
We added a criterion for Fedora 21 Final:
"All applications installed by default in Fedora Workstation must comply
with each MUST and MUST NOT guideline in the Applications and Launchers
policy."
https://fedoraproject.org/wiki/Workstation/Guidelines/Applications_and_La...
that policy includes this:
"App launchers MUST have a unique[3] 128×128 launcher icon with an alpha
channel and a matching High Contrast icon."
so effectively any default-installed app in Workstation lacking a high
contrast icon blocks the release of Fedora. We do indeed have two such
bugs on the current blocker list:
https://bugzilla.redhat.com/show_bug.cgi?id=1160499
https://bugzilla.redhat.com/show_bug.cgi?id=1130794
someone at the meeting wondered whether we really want to block Fedora
releases for this, and mclasen said:
<mclasen> I don't think it justifies blocking the release, tbh
<mclasen> but it is nice to have some pressure for getting those gaps
closed
We're quite strict about not using the blocker process for this kind of
thing these days, and I still think that's the best policy. One of the
problems we identified with the old blocker process back around F12-F14,
when we solidified the current process and added the "freeze
exception" (at the time, "nice to have") concept was that (ab)using the
blocker list as a list of 'priority' bugs meant no-one was really clear
on what bugs would actually literally block the release, and what bugs
would just be hand-waved when it came time to decide whether we shipped.
Since then we've stuck to the policy that only bugs we would actually
delay the release for go on the blocker list, and I think that's worked
out well and we should try to stick with it.
So with that in mind, can I ask if we really want to block Fedora
releases on high-contrast icons? If the consensus is 'yes', then fine,
no need for action. If 'no', then we'd need to amend either the release
criterion or the Applications and Launchers policy in some way - for
instance:
"App launchers MUST have a unique[3] 128×128 launcher icon with an alpha
channel and SHOULD include a matching High Contrast icon."
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
8 years, 10 months
Re: dnf isn't installed by default with net install
by Stephen Gallagher
On Sat, 2014-11-22 at 00:01 -0700, Chris Murphy wrote:
> On Fri, Nov 21, 2014 at 5:42 PM, Stephen Gallagher <sgallagh(a)redhat.com> wrote:
> >
> >
> >
> >> On Nov 21, 2014, at 7:35 PM, Chris Murphy <lists(a)colorremedies.com> wrote:
> >>
> >> Is this intentional? I installed from
> >> Fedora-Server-netinst-x86_64-21_TC2.iso and post install dnf isn't
> >> present.
> >>
> >
> >
> > Yes, yum is still the default in F21. The plan is to switch to dnf in F22.
>
> I realize that but on Workstation both yum and dnf are installed in a
> default installation. In comparison it seems like it's missing on
> Server. Maybe it's superfluous on Workstation, but as a transitional
> release before the official switch I think it's a good idea to have
> both. Encourage more widespread testing, simply because it's already
> installed, while being able to fallback to yum when there's breakage.
> If F22 is the overlap release, then nevermind. But if we'd default to
> dnf *and* not install yum for F22, that seems like quitting yum cold
> turkey.
>
I'm CCing the Workstation list here. I'm actually not sure that
inclusion of DNF on Workstation is intentional.
That being said, I doubt that having DNF installed by default would
change the amount of testing it gets. Anyone who actually knows that it
exists is fully capable of running 'yum install dnf' (and if they don't
know how to do that, they're *probably* not going to be a terribly
effective tester of DNF).
I wouldn't call it "quitting yum cold turkey", either. Even when we make
the switch to DNF-by-default, yum is going to remain in the repository
(though on life-support, not actively developed). So it's still there
for people to fall back on if DNF truly can't meet their needs.
8 years, 10 months
Please vote: xdg base dir spec
by Rahul Sundaram
Hi
This is request for the WG members to vote on requiring all defaults
apps/components in the workstation installation be compliant with the xdg
base dir spec.
Rationale:
This is more or less the current status already with very few but high
profile components including Firefox and NSS. They could be grandfathered
in for now with a time limit for them to be compliant. If more apps were
compliant with the spec, it helps in maintenance of the system, especially
backups. It would also help convince upstreams to take this spec more
seriously if a major distribution requires it.
Prior discussions at
https://lists.fedoraproject.org/pipermail/desktop/2014-October/010979.html
Thank you
Rahul
8 years, 10 months
Workstation WG Recap 2014-Nov-19
by Paul W. Frields
Minutes: http://meetbot.fedoraproject.org/fedora-meeting/2014-11-19/workstation.20...
Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting/2014-11-19/workstation.20...
Log: http://meetbot.fedoraproject.org/fedora-meeting/2014-11-19/workstation.20...
* * *
===============================
#fedora-meeting: Workstation WG
===============================
Meeting started by stickster at 16:00:40 UTC. The full logs are
available at
http://meetbot.fedoraproject.org/fedora-meeting/2014-11-19/workstation.20...
.
Meeting summary
---------------
* Roll call! (stickster, 16:00:59)
* Branding status (stickster, 16:05:34)
* Logo extension and Anaconda branding work still underway, via
exception process. Waiting on new fedora-logos package. Still think
we can get this done. (stickster, 16:13:14)
* XDG base dir proposal (stickster, 16:13:24)
* REJECTED: The WG will not require XDG basedir (stickster, 16:17:06)
* stickster withdraws the recommendation proposal (stickster,
16:24:55)
* ACTION: stickster will work on some extra text in the wiki where we
can make recommendations on specs for new apps (stickster,
16:25:17)
* Open seat (stickster, 16:26:16)
* AGREED: rdieter will fill ltinkl seat on Workstation WG, effective
immediately (stickster, 16:56:24)
* ACTION: stickster will follow up on possible add'l seat availability
(stickster, 16:56:49)
* Final release collateral (stickster, 16:56:58)
* Need WG members and contributors to help review Final release
announcement for F21 (stickster, 16:58:20)
* Also, screenshots welcome at
https://fedoraproject.org/wiki/F21_screenshots_library (stickster,
16:58:32)
* ACTION: stickster Put latest Final release announcement WS stuff on
wiki (stickster, 16:59:41)
* ACTION: stickster Invite Docs help with WS rel-ann (stickster,
16:59:48)
Meeting ended at 17:00:58 UTC.
Action Items
------------
* stickster will work on some extra text in the wiki where we can make
recommendations on specs for new apps
* stickster will follow up on possible add'l seat availability
* stickster Put latest Final release announcement WS stuff on wiki
* stickster Invite Docs help with WS rel-ann
Action Items, by person
-----------------------
* stickster
* stickster will work on some extra text in the wiki where we can make
recommendations on specs for new apps
* stickster will follow up on possible add'l seat availability
* stickster Put latest Final release announcement WS stuff on wiki
* stickster Invite Docs help with WS rel-ann
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* stickster (93)
* kalev (20)
* jwb (19)
* cschalle_ (17)
* aday_ (8)
* sgallagh (7)
* zodbot (7)
* ryanlerch (6)
* otaylor (6)
* mcatanzaro (5)
* rdieter (3)
* langdon (1)
* Southern_Gentlem (1)
* zeenix (1)
* jsmith (1)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
--
Paul W. Frields http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://redhat.com/ - - - - http://pfrields.fedorapeople.org/
The open source story continues to grow: http://opensource.com
8 years, 10 months
Call for agenda for Workstation WG meeting
by Paul W. Frields
Next meeting is tomorrow, Wed 2014-Nov-19 at 1600 UTC/11:00am US-EST.
Please feel free to suggest additional matters for the agenda.
Current agenda items are:
* Status of branding (including technical work)
* XDG base dir proposal (not yet vote-resolved on list)
* (a) Shall we require that default apps in Fedora Workstation use
XDG base directories as shown in the freedesktop spec?
* (b) If not (a), shall we *recommend* default apps in Fedora
Workstation use XDG base directories as shown in the freedesktop
spec?
* Open seat still available -- candidates are Allan Day and Rex Dieter
* Final release collateral
* Release announcement
* Screenshots
--
Paul W. Frields http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://redhat.com/ - - - - http://pfrields.fedorapeople.org/
The open source story continues to grow: http://opensource.com
8 years, 10 months
NTP switch in gnome-control-center is broken
by Michael Catanzaro
Hi,
Let's decide what to do about
https://bugzilla.redhat.com/show_bug.cgi?id=1136905
Long story short: timedated no longer supports NTP clients other than
timesyncd (the new systemd NTP client). Oversimplifying, the chrony
developers say that chrony is better than timesyncd, and the systemd
developers say that timesyncd is better than chrony.
We need to remove chrony from the default install and figure out what to
do for users upgrading to F21 (if we do not uninstall chrony, the switch
will be broken), or patch out the change to timedated, or build systemd
without timedated and provide our own implementation of it, or patch
gnome-control-center.
None of these seem like particularly good options. Removing chrony seems
like an easy solution, but I'm not sure how we could handle upgrades
without hurting users who don't want chrony to be removed.
Michael
8 years, 10 months