test February 2014

test@lists.fedoraproject.org

52 participants
180 discussions

[Fedora QA] #424: Proposed Test Day - KDE 4.11
by fedora-badges 11 Aug '14

11 Aug '14

#424: Proposed Test Day - KDE 4.11 ----------------------+------------------------ Reporter: mbriza | Owner: Type: task | Status: new Priority: major | Milestone: Fedora 20 Component: Test Day | Version: Keywords: | Blocked By: Blocking: | ----------------------+------------------------ = phenomenon = KDE Plasma Workspaces test day for Fedora 20 Proposed date is 7th November, 2013. = implementation recommendation = We, as the KDE SIG need to test our three proposed features: * KDE Plasma Workspaces 4.11 * Plasma-nm * SDDM as the default KDE display manager instead of KDM as well as the regular KDE tests ran before every Fedora release -- Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/424> Fedora QA <http://fedorahosted.org/fedora-qa> Fedora Quality Assurance

1 3

[Fedora QA] #420: Power management testday
by fedora-badges 11 Aug '14

11 Aug '14

#420: Power management testday ----------------------+------------------------ Reporter: jskarvad | Owner: Type: task | Status: new Priority: major | Milestone: Fedora 20 Component: Test Day | Version: Keywords: | Blocked By: Blocking: | ----------------------+------------------------ We would like to run Power management test day. The arrangement will be similar to our previous Power management test days. We can prepare the live medium ourselves. We propose 2013-11-14, but any other date should fit. -- Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/420> Fedora QA <http://fedorahosted.org/fedora-qa> Fedora Quality Assurance

1 3

[Fedora QA] #409: Fedora 20 i18n Test Day
by fedora-badges 11 Aug '14

11 Aug '14

#409: Fedora 20 i18n Test Day ----------------------+------------------------ Reporter: aalam | Owner: Type: task | Status: new Priority: major | Milestone: Fedora 20 Component: Test Day | Version: Keywords: | Blocked By: Blocking: | ----------------------+------------------------ I18N (Internationalization) Test Day Test Date: TBD Fedora 20 Schedule: http://fedoraproject.org/wiki/Releases/20/Schedule Required: Live ISO, it may not be same as l10n test day. -- Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/409> Fedora QA <http://fedorahosted.org/fedora-qa> Fedora Quality Assurance

1 10

[Fedora QA] #408: Fedora 20 Translation Test Day
by fedora-badges 11 Aug '14

11 Aug '14

#408: Fedora 20 Translation Test Day ----------------------+------------------------ Reporter: aalam | Owner: Type: task | Status: new Priority: major | Milestone: Fedora 20 Component: Test Day | Version: Keywords: | Blocked By: Blocking: | ----------------------+------------------------ = phenomenon = Translation Test day for Fedora 20. Test Date: need to decide. It is before 'Software Translation Freeze' (2013-10-08). proposed date: Thursday Sep 26 (2013-09-26) = implementation recommendation = - need to review test cases for gnome-3.10 - need to create test for Anaconda fltg team will help for that. -- Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/408> Fedora QA <http://fedorahosted.org/fedora-qa> Fedora Quality Assurance

1 9

[Fedora QA] #407: Bluetooth Test Day
by fedora-badges 11 Aug '14

11 Aug '14

#407: Bluetooth Test Day ----------------------+------------------ Reporter: martix | Owner: Type: task | Status: new Priority: major | Milestone: Component: Test Day | Version: Keywords: | Blocked By: Blocking: | ----------------------+------------------ I'd like to do Bluetooh Test Day on 2013-10-17 Change: http://fedoraproject.org/wiki/Changes/Bluez5 -- Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/407> Fedora QA <http://fedorahosted.org/fedora-qa> Fedora Quality Assurance

1 6

slow mirror workaround?
by Felix Miata 24 Apr '14

24 Apr '14

Trying to yum upgrade 19 is stuck on a mirror with no useful throughput. What kind of workaround for this is available? Nothing jumps at me in the yum man page. How do I specify to use a particular mirror know to work? -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/

6 8

Very rough storage validation matrix draft
by Adam Williamson 02 Apr '14

02 Apr '14

Hi, folks. So, our current set of storage validation tests is just a grab-bag of stuff we've held over from oldui, added and patched piecemeal; it's not very coherent or consistent and it doesn't come close to exercising all of the storage stuff in the installer. We wind up sort of inventing test plans particularly for custom partitioning as we go along, with the consequence that we're not sure what we're going to test, what's really important to test when, etc etc. I've made a few abortive tries at re-doing the storage tests and basically given up because it's just a hideous thing to try and cover, but I thought while I'm still on a momentum roll from F20 and remember some of the issues that came up during F20 validation, I'd take another cut at it. Here's what I came up with: https://fedoraproject.org/wiki/User:Adamwill/Draft_storage_matrix The proposal is to separate out storage testing from the 'installation testing' matrix as its own matrix, because I think we can get further with flexible columns, and it's such a big area the installation matrix gets pretty unwieldy with all the storage tests stuffed into it. remember this is *extremely* rough. It may be that we don't think my organizational approach here is right at all and we should tear it up and start over. But I thought I'd throw it out there for comments. Most of the tests, obviously, don't exist yet; they'd be fairly trivial to write, I think the hard part of the problem here is deciding what we want to test, and how to organize it. It's an extremely difficult area; there are so many different variables to storage configuration that it's utterly impractical to try and cover every possible permutation even assuming the user uses the interface perfectly. What I've tried to do is come up with something which would exercise most of the areas we really seem to want to care about, without being utterly unwieldy. It is still very large, that's probably the first thing you'd notice about it. I doubt we could run this on every build. What I think would be a nice complement is a somewhat improved version of testcase_stats - http://testdays.qa.fedoraproject.org/testcase_stats/ - which could track both dimensions of each matrix, so we could try to strategically ensure every spot on the table is covered at least once per milestone or once per release, say. Here's a quick key to the test names for tests I've made up which may not be self-explanatory, yell if you need explanations of any of the others: ----- guided_multi_empty - the 'multi' means multiple disks, this is checking we correctly autopart to multiple disks. in the custom tests, 'auto' means 'using the autopart mechanism inside custom partitioning', the blue text that lets you automatically create a set of volumes. existing_retain_home - this is the classic 'install over an existing Fedora install, retain the /home partition' trick. existing_precreated - this would be a test for running the installer with a set of empty volumes that you just wanted to assign mount points to. add_to_container - add a new volume to free space within an existing container. assign_* tests - these are for specifying that a given partition or container must be on a particular disk. help_text - just checks the 'help' screen works. small_disks - this would be a test where you check anaconda correctly refuses to install to a disk that's too small. cancel_encryption - this would be to check what happens if you cancel out of the 'enter a passphrase' dialog. shrink_maximum - try to shrink a partition to the largest possible size (right-hand end of the slider) shrink_minimum - shrink a partition as small as possible (left-hand end of the slider) shrink_no_size_change - set action for a partition to 'shrink' but don't actually change its size shrink_unusual_sizes - this would be for the bug we discovered in f20, test the shrinker handles partitions with 'weird' sizes shrink_change_action - this is just for changing the 'action' in shrink a bunch of times and making sure it doesn't explode multiple_trips - run through Installation Destination more than once custom_resize_no_size - just clear the 'desired size' field for a partition and hit 'update settings' custom_resize_invalid_unit - try entering something like '30 ZX' in the desired size field custom_resize_return - change the desired size and then change it back to the original value custom_invalid_mount_point - try entering a mount point name that is not allowed (invalid characters, spaces or something) custom_invalid_filesystem - try putting a system partition on vfat or bios boot or swap or something ---- Please, absolutely all comments, suggestions, alternative proposals, flames etc etc welcome. I'm sure we could improve this proposal or do better, but I think we have to try and do _something_ better than our current tests. And I think drawing up a table like this, if nothing else, illustrates what a hard task this is... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

5 26

Draft terminal application test case
by Adam Williamson 14 Mar '14

14 Mar '14

Proposing a new draft release validation test case: https://fedoraproject.org/wiki/User:Adamwill/Draft_QA_Testcase_desktop_term… this is a fairly simple test case that just checks that a terminal application works in a desktop environment. It would be added to the desktop matrix along with the browser test case, to cover the lack of a test case to enforce the terminal part of the Alpha criterion "It must be possible to run the default web browser and a terminal application from all release-blocking desktop environments." Comments, improvements, suggestions etc welcome as always! As this is pretty straightforward I'm planning to put it into production pretty soon if there's no negative feedback. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net

4 7

How to calculate priority for missing tests or %check
by Alexander Todorov 03 Mar '14

03 Mar '14

Hi guys, I've started working to identify packages with missing upstream test suites or not running the tests in %check. Having a list of hundreds of packages now I need to prioritize them somehow. This will help in later steps when spec files need to be fixed or somebody wants to start working with upstream on writing a test suite. My idea is to take all bugs against Fedora in the last few years (or releases). Packages with bigger number of bugs receive higher priority than those with less. Then based on this prioritize. How long should the time frame be? I'm thinking 3 to 5 years. Where low/medium/high priority boundaries are ? (could be 30%, 60%, 90% for example). Do you have other ideas how to calculate priority of these items? Thanks, Alex

10 23

Re: XFS on Fedora i686, armv7hl
by Chris Murphy 01 Mar '14

01 Mar '14

On Feb 27, 2014, at 8:06 AM, Eric Sandeen <sandeen(a)sandeen.net> wrote: > On 2/26/14, 11:37 PM, Chris Murphy wrote: >> Hi, >> >> Fedora is considering XFS as their default file system. They support >> three primary architectures: x86_64, i686, and armv7hl. Do XFS devs >> have any reservations about XFS as a default file system on either >> i686, or arm? > > As Dave said, we rely on others to do ARM testing for the most part, > though I've certainly jumped in and debugged some issues from time > to time. > > It'd be super if Fedora could run the xfstests test suite on arm > as part of QE. I'd be more than happy to help get that started > if people are interested. I don't know that Fedora QA has the resources to do this, but I'll cc the Fedora test@ (QA) arm@ lists. If these are highly automatable tests it might be possible, if they have the hardware. More likely I think it's that we need some ARM community folks to look at splitting up some of this work. I'm not sure yet what concerns the ARM group might have with XFS either as this hasn't been decided, but the Fedora Server product working group is slightly leaning toward XFS by default. Performance and CPU hit wise on x86_64, XFS seems to match up well with ext4 and maybe even a bit better ratio of throughput/CPUtime for booting workload (systemd is parallel!) so if were the same on ARM XFS could work out slightly better for them. Chris Murphy

2 2

← Newer
1
2
3
4
5
6
7
8
...
18
Older →

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 February 2014