test June 2014

test@lists.fedoraproject.org

49 participants
177 discussions

[Fedora QA] #297: Review release criteria for Fedora 18
by fedora-badges 30 Jan '15

30 Jan '15

#297: Review release criteria for Fedora 18 -----------------------------------------+------------------------ Reporter: adamwill | Owner: pschindl Type: task | Status: new Priority: major | Milestone: Fedora 18 Component: Proventester Mentor Request | Version: Keywords: | Blocked By: Blocking: | -----------------------------------------+------------------------ Petr suggests on the F17 retrospective: "We should reviewed release criteria, dismiss all which are obsolete and maybe add some new (like we did for PXE). This step should be done in cooperation with other teams (like anaconda and FESCo)." This is kind of a follow-up to https://fedorahosted.org/fedora- qa/ticket/151 . -- Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/297> Fedora QA <http://fedorahosted.org/fedora-qa> Fedora Quality Assurance

1 4

[Fedora QA] #277: Add ARM to release criteria / validation process somehow
by fedora-badges 30 Jan '15

30 Jan '15

#277: Add ARM to release criteria / validation process somehow ----------------------+------------------------ Reporter: adamwill | Owner: adamwill Type: task | Status: new Priority: critical | Milestone: Fedora 17 Component: Wiki | Version: Keywords: arm | Blocked By: Blocking: | ----------------------+------------------------ = phenomenon = ARM is becoming increasingly important to releases. Currently we have no kind of formal validation process for ARM images. Let's work with the ARM group to improve this, so we can test whatever is most important to them. = background analysis = ARM deployment is significantly different from x86: the standard way to do things is to provide a pre-built image to dump onto the system, not to 'install' via anaconda. So a lot of our test suite, which is based around anaconda, may not be entirely appropriate to ARM. Similarly, the desktop validation stuff isn't likely to be super-interesting to them, as desktop isn't currently a priority for ARM and things at that high a level ought to pretty much 'just work'. We should figure out with the ARM team what it would be most useful to test, and how to work testing into their release process. = implementation recommendation = We may need to write a few new tests, then I think we should design an ARM-specific validation matrix, which may be much smaller than the main ones. To start with we may also want to start separate ARM release criteria pages, to codify the things which are most important to ARM releases. -- Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/277> Fedora QA <http://fedorahosted.org/fedora-qa> Fedora Quality Assurance

1 9

[Fedora QA] #275: Create test plan for ARM
by fedora-badges 29 Jan '15

29 Jan '15

#275: Create test plan for ARM ----------------------+------------------ Reporter: jdulaney | Owner: Type: task | Status: new Priority: major | Milestone: Component: Trac | Version: Keywords: | Blocked By: Blocking: | ----------------------+------------------ I've decided to create this ticket to track this. -- Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/275> Fedora QA <http://fedorahosted.org/fedora-qa> Fedora Quality Assurance

1 3

[Fedora QA] #272: Add changelog to TC/RC announce mails
by fedora-badges 29 Jan '15

29 Jan '15

#272: Add changelog to TC/RC announce mails -------------------------+------------------------ Reporter: adamwill | Owner: robatino Type: enhancement | Status: new Priority: major | Milestone: Fedora 17 Component: Trac | Version: Keywords: | Blocked By: Blocking: | -------------------------+------------------------ = problem = cwickert pointed out in the F16 QA retrospective that the information on what has changed between TC / RC builds is not easy to find for those outside of QA. = enhancement recommendation = We should include a changelog in the TC / RC announce mails. The information can usually be found in the rel-eng trac ticket - e.g. https://fedorahosted.org/rel-eng/ticket/4967 for F16 final - although sometimes, also, packages are pushed to stable between TC / RC builds: these would not always be listed out in the trac ticket. After TC1, the TC / RC announce mails should list all the new builds included in the build compared to the previous build, and any other changes (e.g. kickstart or compose process change to fix some bug or other). -- Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/272> Fedora QA <http://fedorahosted.org/fedora-qa> Fedora Quality Assurance

1 19

[Fedora QA] #237: tests to verify that torrents and mirrors contain signed checksum files
by fedora-badges 29 Jan '15

29 Jan '15

#237: tests to verify that torrents and mirrors contain signed checksum files ----------------------+----------------------------------------------------- Reporter: robatino | Owner: Type: task | Status: new Priority: major | Milestone: Component: Wiki | Version: Keywords: | ----------------------+----------------------------------------------------- In many of the last several releases (11, 13, 14, and now 16), at least some of the Alpha or Beta torrents contain only unsigned checksum files. This would be easy to prevent by examining the .torrent files, which contain file sizes (signing a checksum file adds about 1K to the size). Unfortunately, at present these are not made available for testing prior to being posted on http://torrent.fedoraproject.org , and when the problem is pointed out, no matter how quickly, one is told that the torrent can't be replaced since people are already downloading it. This makes it important to catch the problem in advance. Many (but not all) of the torrent files for the last several releases are still available at http://torrent.fedoraproject.org/torrents/ and http://torrent.fedoraproject.org/spins/ , and can be examined for example with gtorrentviewer. I have not checked any older than 11, and not all the ones after that are available, so the above list of affected releases is probably incomplete. A less serious issue is when the checksum files get signed more than once. For example, the checksum files for F15 Final install discs were signed twice, first for the torrents and again for the mirrors - see http://robatino.fedorapeople.org/checksums/15-Final/Fedora/ . The checksums are identical, and both signatures are valid, but still, it shouldn't happen. Looking at https://fedoraproject.org/wiki/Release_Engineering_Release_Tickets , it says that for Alpha and Beta, the torrents should be staged before the mirrors, but the reverse for Final. I've asked why on #fedora-releng but gotten no response yet. It says nothing about signing the checksum files, though the linked page https://fedoraproject.org/wiki/Stage_final_release_for_mirrors (under the section "Final") mentions it. This may explain why Alpha and Beta torrents are much less likely to have signed files. If possible, it would be nice for the order (torrents vs. mirrors) to be the same for all three, and in any case, the checksum files should be signed once and then used for both torrents and mirrors. None of this is currently documented. -- Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/237> Fedora QA <http://fedorahosted.org/fedora-qa> Fedora Quality Assurance

1 16

[Fedora QA] #261: Revise upgrade test case set
by fedora-badges 29 Jan '15

29 Jan '15

#261: Revise upgrade test case set -----------------------------------------+---------------------------------- Reporter: adamwill | Owner: Type: task | Status: new Priority: major | Milestone: Fedora 17 Component: Proventester Mentor Request | Version: Keywords: | -----------------------------------------+---------------------------------- Our present upgrade test cases are probably a sub-optimal set. We exercise various rarely-used choices - bootloader action, and text upgrade path - but don't exercise more common variations, like installed package sets, install media, and disk layouts. While we can't commit to supporting absolutely any upgrade, we should cover at least some _more_ cases in order to catch major fails. Based on the experience in F16 and the recommendations in the retrospective, I'd suggest we could consider dropping or downgrading the importance of some tests, perhaps: * QA:Testcase_Anaconda_Upgrade_Skip_Bootloader * QA:Testcase_Anaconda_Upgrade_Skip_Bootloader_Text_Mode * QA:Testcase_Anaconda_Upgrade_Update_Bootloader_Text_Mode and add test cases for all or some of the following scenarios (please add any other suggestions as comments): * upgrade from image written to USB stick (livecd-iso-to-disk) * upgrade with KDE (and possibly Xfce and LXDE as 'optional' test cases) * upgrade an EFI install (see also https://fedorahosted.org/fedora- qa/ticket/256 for organizational issues here) * upgrade with bootloader on first partition (not MBR) * upgrade with separate /usr , /home and /var partitions * upgrade a RAID install This should be completed ideally by Fedora 17 Alpha phase, and definitely by Beta phase (when upgrade issues become blockers). -- Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/261> Fedora QA <http://fedorahosted.org/fedora-qa> Fedora Quality Assurance

1 13

[Fedora QA] #227: Document SOP for acceptance test event
by fedora-badges 29 Jan '15

29 Jan '15

#227: Document SOP for acceptance test event -------------------+-------------------------------------------------------- Reporter: rhe | Owner: twu Type: task | Status: new Priority: major | Milestone: Fedora 16 Component: Wiki | Version: Keywords: | -------------------+-------------------------------------------------------- So far we don't have a sop document for acceptance test events, which is needed to clarify the procedure, see other sops: * http://fedoraproject.org/wiki/Category:QA_SOPs Assign this task to twu as he's been leading this event. Feel free to take if anyone is interested in this. -- Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/227> Fedora QA <http://fedorahosted.org/fedora-qa> Fedora Quality Assurance

1 21

[Fedora QA] #221: Reduce Blocker Bug Review Meeting Length
by fedora-badges 29 Jan '15

29 Jan '15

#221: Reduce Blocker Bug Review Meeting Length -------------------------+-------------------------------------------------- Reporter: tflink | Owner: Type: enhancement | Status: new Priority: major | Milestone: Fedora 16 Component: Trac | Version: Keywords: | -------------------------+-------------------------------------------------- == Description == While the [https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting blocker bug review meetings] are very much a necessary thing, they have a tendency to be long, tedious and not a whole lot of fun for those involved. During the Fedora 15 retrospective, there was a request to streamline the process in order to distribute the workload and avoid more 4+ hour meetings. Any proposals on how to reduce the length of the meetings while maintaining their utility would be much appreciated. == Proposals == Pending discussion in comments and email -- Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/221> Fedora QA <http://fedorahosted.org/fedora-qa> Fedora Quality Assurance

1 15

[Fedora QA] #152: Test Cases Management
by fedora-badges 29 Jan '15

29 Jan '15

#152: Test Cases Management ---------------------------+------------------------------------------------ Reporter: rhe | Owner: rhe Type: enhancement | Status: new Priority: major | Milestone: Fedora 15 Component: Wiki | Version: Keywords: retrospective | ---------------------------+------------------------------------------------ = problem = We've been using mediawiki to manage tests and record results, though it's easy to approach, it has limitations such as managing, tracking and querying cases+results. So is it time for us to consider another solution such as TCMS? = analysis = Here I quoted the suggestion from Victer Chen: some advantages of TCMS: * Better to record, track and query test results, * Allow user focus on test contents instead of document maintenance. * Share test cases However, it couldn't be flexible as wiki. I think the most important things need balance are below: - Barriers Fedora should provide very low barriers. TCMS could be configured to allow anonymous user login and limit it's permission. Also, we can consider using fedora account to login TCMS. - Safety Wiki provides the ability to rollback content easily, while TCMS couldn't. What TCMS can do is recording all the history and allow user recovery it manually. But if we configure the permission well, it should not be a big problem. = enhancement recommendation = Work with TCMS team and package it to Fedora. Set up the system and use it in a small scale first. If it turns out good, enlarger the scale. -- Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/152> Fedora QA <http://fedorahosted.org/fedora-qa> Fedora Quality Assurance

4 25

[Fedora QA] #81: Add i18n release criteria
by fedora-badges 29 Jan '15

29 Jan '15

#81: Add i18n release criteria ---------------------------+------------------------------------------------ Reporter: jlaska | Owner: Type: enhancement | Status: new Priority: major | Milestone: Fedora 14 Component: Wiki | Version: Keywords: retrospective | ---------------------------+------------------------------------------------ = problem = See [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=571900 RHBZ#571900 - Keyboard mapping not correct (USA instead of Belgium) when first login after install Fedora 13 Alpha] = analysis = * Currently we don't have i18n installation cases, so local language install is not tested as a demand. Untranslated pages are still existing after RC test. Such cases needed be added in test as well as release criteria. * Does the Fedora i18n team have any release criteria to propose? * RHBZ #571900 pointed out the need for a better understanding of how the language and keymap installer selections impact the installed system. = enhancement recommendation = Recommend reviewing the release criteria to ensure expectations are captured around propagating language and keymap settings from install to desktop login (/etc/sysconfig/i18n, image:Package-x-generic-16.pnggdm etc...). It may also be advised to coordinate with the installer team so that bugs can be filed for any missing functionality. -- Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/81> Fedora QA <http://fedorahosted.org/fedora-qa> Fedora Quality Assurance

1 8

← Newer
1
2
3
4
5
6
7
...
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 June 2014