Fedora Council report
by Adam Williamson
Hi, folks! So I'm following up again on the request from the Council
that we send someone to report on the QA project's status. The proposed
date was 2015-06-08.
At the last QA meeting (on 2015-05-04) I volunteered to do it, then
realized I won't be able to on 2015-06-08 as I'll be on a plane. So, we
have two choices: either someone else volunteers to do the report, or
we ask the Council if we can change the date. Is anyone else interested
in doing the report? Please reply if so!
The other thing to settle is what we actually want to report. Matt
provided the following guidelines:
- the current state of the subproject
- future plans
- things the team needs from the rest of the project
- any blockers we can help unblock
- big resource requests?
I have some initial thoughts, and it'd be good if anyone else can chip
in: whoever reports to the Council, I think they should be acting as a
representative for all of us as a whole, so it'd be good to gather
everyone's thoughts together for the representative to pass along.
Current state
-------------
I'd say we have a fairly solid process in place now for release
validation, and everyone's probably more or less familiar with it. We
also have the update testing process nailed down, though I still think
we can improve it in some ways, and we *still* want Bodhi 2.0 :)
We have taskotron running for some package tests and openQA for some
installation validation tests. openQA is I think still running on
openSUSE boxes, but we have some work done on containerization to
potentially move them to Fedora hosts (and I've also been working on
packaging the openQA bits for Fedora).
I think we might still be lacking a bit in terms of Change testing;
there's a personpower issue there, though. We usually wind up only
cherrypicking the most obviously potentially disruptive Changes for
testing, and usually from the perspective of 'does this break the
release'; we rarely manage to find the time to test Changes *in
themselves* and help make sure they work well.
Future plans
------------
We have a fairly well-defined roadmap for Taskotron development, I
believe; we could broaden its actual test coverage, but I think we
still have some infrastructure work that probably needs nailing down
before we can focus on that, particularly in terms of the disposable
test client work, and also I believe in terms of results management.
I'd definitely like to see us extending openQA coverage in the post-F22
'quiet time'. There are still many validation tests that could
successfully be automated, which gives us much better coverage and
reduces the manual testing burden. I'm certainly intending to help work
on this. We could also consider soliciting wider contributions of
openQA tests; I think the openQA experiment has been fairly successful,
and I could certainly envisage some cases where maintainers might want
to have tests related to their packages in openQA.
Something I've been kicking around with release engineering a bit, and
which will probably come up at Flock, is the possibility of revising
the whole TC/RC approach to release composing. It's getting fairly old,
and is built on some assumptions that are becoming somewhat outdated:
that building and consuming composes are inherently expensive
operations and hence need to be 'rationed' and carefully, manually
handled. In an ideal world, I think it would be nice to take a more
modern, CI-ish approach: we should be doing the whole compose process
daily (not just boot.isos and lives) and running automated tests on the
daily composes (openQA is already capable of this), and improving the
efficiency of the process whereby updates get into composes. The
'special package requests' in TC/RC compose requests have become kinda
a permanent feature, but they were never meant to be. I'd prefer if we
could make the process whereby updates move to stable vastly more
efficient, and perhaps have a slightly different process for handling
builds we want to put in TCs/TCs but which we don't yet want to push
stable (the most common case being the packages that are actually
involved in *doing composes*, so in order to test them, we need to
build composes with them) - something more visible and less clunky than
the current 'list them in TC/RC requests and they go into a manually
maintained bleed repo' approach.
Things we need
--------------
Kinda tied in to the above: Bodhi 2.0, and more efficient releng
processes, are the big two I can think of - faster update pushes and
composes. I think tflink and kparal are in a better position than I to
know about any major resources we need.
Hope that kicks off a few thoughts from other folks! Please don't be
shy, and pitch in with any thoughts you have :)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
8 years, 10 months
[Fedora QA] #467: DNF Migration: Rolekit Testing
by fedora-badges
#467: DNF Migration: Rolekit Testing
---------------------------+------------------------
Reporter: roshi | Owner:
Type: task | Status: new
Priority: major | Milestone: Fedora 22
Component: Trac | Version:
Keywords: dnf_migration | Blocked By:
Blocking: |
---------------------------+------------------------
Rolekit utilizes yum for deploying it's roles (which is currently limited
to domain controller and database), which means it needs to get ported to
dnf and tested. Hopefully a majority of the testing will fall under
general release validation testing, but we need someone to track this
testing effort for F22.
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/467>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
8 years, 11 months
[Fedora QA] #466: DNF Migration: Software Center and Apper
by fedora-badges
#466: DNF Migration: Software Center and Apper
---------------------------+------------------------
Reporter: roshi | Owner:
Type: task | Status: new
Priority: major | Milestone: Fedora 22
Component: Trac | Version:
Keywords: dnf_migration | Blocked By:
Blocking: |
---------------------------+------------------------
Software Center and Apper both use the same backend tools yum uses. While
this doesn't strictly fall under the umbrella of the DNF migration - we
need someone to keep an eye on these tools and ensure they work. It would
probably be good to have two people handle this, one for Software Center
and one for Apper.
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/466>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
8 years, 11 months
[Fedora QA] #465: DNF Migration: FedUp Testing
by fedora-badges
#465: DNF Migration: FedUp Testing
---------------------------+------------------------
Reporter: roshi | Owner:
Type: task | Status: new
Priority: major | Milestone: Fedora 22
Component: Trac | Version:
Keywords: dnf_migration | Blocked By:
Blocking: |
---------------------------+------------------------
We'll need testing of F20 to F22 upgrades. Both have different installed
package sets due to utilizing different depsolvers which could potentially
cause issues with upgrades. We need someone to handle the testing effort
for FedUp going forward - this will likely require more testing during the
F23 cycle than the F22 cycle.
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/465>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
8 years, 11 months
