test May 2015

test@lists.fedoraproject.org

88 participants
225 discussions

[Fedora QA] #471: amend/remove "release notes" criterion
by fedora-badges 13 Jun '15

13 Jun '15

#471: amend/remove "release notes" criterion ------------------------------+------------------------ Reporter: kparal | Owner: Type: task | Status: new Priority: minor | Milestone: Fedora 22 Component: Release criteria | Version: Keywords: | Blocked By: Blocking: | ------------------------------+------------------------ It was agreed that our "release notes" criterion will be changed or removed, in this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1221920 This ticket is to track this task. -- Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/471> Fedora QA <http://fedorahosted.org/fedora-qa> Fedora Quality Assurance

1 3

conflict between latest fedora-release and systemd (rawhide)
by kevin martin 12 Jun '15

12 Jun '15

Just an FYI, the latest rawhide update gives an error about usr/lib/systemd/system-preset/90-default.preset conflicting between the .13 version of fedora-release and systemd. Regards, Kevin

5 16

Fedora Council report
by Adam Williamson 11 Jun '15

11 Jun '15

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

5 7

[Fedora QA] #469: Proposed Test Day - Cloud/Atomic Test Day
by fedora-badges 02 Jun '15

02 Jun '15

#469: Proposed Test Day - Cloud/Atomic Test Day -----------------------+------------------------ Reporter: dustymabe | Owner: Type: task | Status: new Priority: major | Milestone: Fedora 22 Component: Test Day | Version: Keywords: | Blocked By: Blocking: | -----------------------+------------------------ We will be testing the Fedora 22 Cloud and Atomic images on May 7th. The following pages will be updated with more information as it comes along: https://fedoraproject.org/wiki/Test_Day:2015-05-07_Cloud https://fedoraproject.org/wiki/Test_Day:2015-05-07_Atomic -- Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/469> Fedora QA <http://fedorahosted.org/fedora-qa> Fedora Quality Assurance

1 1

[Fedora QA] #467: DNF Migration: Rolekit Testing
by fedora-badges 02 Jun '15

02 Jun '15

#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

1 4

[Fedora QA] #466: DNF Migration: Software Center and Apper
by fedora-badges 02 Jun '15

02 Jun '15

#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

1 9

[Fedora QA] #465: DNF Migration: FedUp Testing
by fedora-badges 02 Jun '15

02 Jun '15

#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

1 2

[Fedora QA] #464: DNF Migration: ABRT Testing
by fedora-badges 02 Jun '15

02 Jun '15

#464: DNF Migration: ABRT Testing ---------------------------+------------------------ Reporter: roshi | Owner: Type: task | Status: new Priority: major | Milestone: Fedora 22 Component: Trac | Version: Keywords: dnf_migration | Blocked By: Blocking: | ---------------------------+------------------------ ABRT will be impacted by the migration away from yum, so we'll need someone to head up testing it for F22. We currently have 36 testcases [0] for ABRT, though some of them will need some love to be fully up to date. [0] http://fedoraproject.org/wiki/Category:Package_abrt_test_cases -- Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/464> Fedora QA <http://fedorahosted.org/fedora-qa> Fedora Quality Assurance

1 2

[Fedora QA] #461: Proposed Test Day - i18n
by fedora-badges 02 Jun '15

02 Jun '15

#461: Proposed Test Day - i18n ----------------------+------------------------ Reporter: tagoh | Owner: Type: task | Status: new Priority: major | Milestone: Fedora 22 Component: Test Day | Version: Keywords: | Blocked By: Blocking: | ----------------------+------------------------ We'd like to propose i18n test day for f22 at 19th March. -- Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/461> Fedora QA <http://fedorahosted.org/fedora-qa> Fedora Quality Assurance

1 9

[Fedora QA] #460: Proposed Test Day - Ipsilon
by fedora-badges 02 Jun '15

02 Jun '15

#460: Proposed Test Day - Ipsilon ----------------------+------------------------ Reporter: rcritten | Owner: Type: task | Status: new Priority: major | Milestone: Fedora 22 Component: Test Day | Version: Keywords: | Blocked By: Blocking: | ----------------------+------------------------ Ownership - Rob Crittenden and the Ipsilon team Time frame - March 12, 2015 Feature(s) - General Ipsilon Testing http://fedoraproject.org/wiki/Changes/Ipsilon -- Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/460> Fedora QA <http://fedorahosted.org/fedora-qa> Fedora Quality Assurance

1 2

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

test May 2015