test September 2014

test@lists.fedoraproject.org

71 participants
261 discussions

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

28 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 28 Jan '15

28 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 28 Jan '15

28 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 28 Jan '15

28 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

[Fedora QA] #61: make VirtioSerial Test cases clearer
by fedora-badges 28 Jan '15

28 Jan '15

#61: make VirtioSerial Test cases clearer ----------------------+----------------------------------------------------- Reporter: liam | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Test Day | Version: Keywords: | ----------------------+----------------------------------------------------- we have VirtioSerial Test cases here: https://fedoraproject.org/wiki/Test_Day:2010-04-08_Virtualization_VirtioSer… but during test day, none of these cases was executed. I think testers did not know how to run these cases, so Amit, could you like to rewrite these cases with template and make it clearer? The good cases can help make VirtioSerial better and better,it also can involve more fedora people in virtio.Thanks in advance. These cases that are written with template for your reference: https://fedoraproject.org/wiki/QA:Fedora_13_Install_Results_Template#Test_M… Or if you don't know how to use template, just write the test step more specific and send the cases to me, I will convert them to standard format. -- Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/61> Fedora QA <http://fedorahosted.org/fedora-qa> Fedora Quality Assurance

1 4

[Fedora QA] #46: Write Test cases for LXDE components.
by fedora-badges 27 Jan '15

27 Jan '15

#46: Write Test cases for LXDE components. ----------------------+----------------------------------------------------- Reporter: johannbg | Owner: johannbg Type: task | Status: new Priority: major | Milestone: Component: Test Day | Version: Keywords: | ----------------------+----------------------------------------------------- An ticket to keep track on LXDE components that need test cases and how to debug pages * PCManFM: File manager, provides desktop icons * LXPanel: Feature-rich desktop panel * LXSession: Standard-compliant X11 session manager with shutdown/reboot/suspend support via HAL ( FEI https://fedoraproject.org/wiki/Features/HalRemoval ) * LXSession-edit: GUI to configure what’s automatically started in LXDE * lxde-settings-daemon: XSettings Daemon * LXInput: Keyboard and mouse settings dialog * LXRandR: Configuration tool for monitors and external projectors * LXAppearance: Feature-rich GTK+ theme switcher able to change GTK+ themes, icon themes, and fonts * LXTask: Lightweight task manager derived from xfce4 task manager * LXTerminal: Desktop-independent VTE-based terminal emulator * LXLauncher: Open source replacement for the Asus Launcher on the EeePC * LXShortcut: Small utility to edit application shortcuts, used by lxpanel and lxlauncher * LXNM (still under development): Lightweight network manager for LXDE supporting wireless connections (not yet in Fedora ) * LXRandR (still under development): Monitor configuring tool * Openbox: Lightweight, standard-compliant, and highly-configurable window manager. * GPicView: A very simple, fast, and lightweight image viewer featuring immediate startup * Leafpad: Lightweight and simple text editor * XArchiver: Lightweight, fast, and desktop-independent gtk+-based file archiver * LXDM: Display manager -- Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/46> Fedora QA <http://fedorahosted.org/fedora-qa> Fedora Quality Assurance

1 7

mount -t nfs delayed
by Felix Miata 23 Oct '14

23 Oct '14

For several weeks, maybe several months, most of my Rawhide installations generate an error trying to mount noauto nfs items in fstab: Job for rpc-statd.service failed. See 'systemctl status rpc-statd.service' and 'journalctl -xn' for details. Output from those: [start]rpc-statd.service - NFS status monitor for NFSv2/3 locking. Loaded: loaded (/usr/lib/systemd/system/rpc-statd.service; enabled) Active: failed (Result: exit-code) since Thu 2014-05-29 00:41:00 EDT; 3min 12s ago Process: 691 ExecStart=/usr/sbin/rpc.statd --no-notify $STATDARGS (code=exited, status=1/FAILURE) May 29 00:40:00 g5eas systemd[1]: Starting NFS status monitor for NFSv2/3 locking.... May 29 00:40:00 g5eas rpc.statd[692]: Version 1.3.0 starting May 29 00:40:00 g5eas rpc.statd[692]: Flags: TI-RPC May 29 00:41:00 g5eas rpc.statd[692]: failed to create RPC listeners, exiting May 29 00:41:00 g5eas systemd[1]: rpc-statd.service: control process exited, code=exited status=1 May 29 00:41:00 g5eas systemd[1]: Failed to start NFS status monitor for NFSv2/3 locking.. May 29 00:41:00 g5eas systemd[1]: Unit rpc-statd.service entered failed state. -- Logs begin at Sat 2014-03-22 18:49:34 EDT, end at Thu 2014-05-29 00:41:00 EDT. -- May 29 00:40:00 g5eas rpcbind[693]: cannot create socket for tcp6 May 29 00:40:00 g5eas systemd[1]: Started RPC bind service. -- Subject: Unit rpcbind.service has finished start-up -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit rpcbind.service has finished starting up. -- -- The start-up result is done. May 29 00:40:07 g5eas systemd[1]: Starting Stop Read-Ahead Data Collection... -- Subject: Unit systemd-readahead-done.service has begun with start-up -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit systemd-readahead-done.service has begun starting up. May 29 00:40:07 g5eas systemd[1]: Started Stop Read-Ahead Data Collection. -- Subject: Unit systemd-readahead-done.service has finished start-up -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit systemd-readahead-done.service has finished starting up. -- -- The start-up result is done. May 29 00:41:00 g5eas rpc.statd[692]: failed to create RPC listeners, exiting May 29 00:41:00 g5eas systemd[1]: rpc-statd.service: control process exited, code=exited status=1 May 29 00:41:00 g5eas systemd[1]: Failed to start NFS status monitor for NFSv2/3 locking.. -- Subject: Unit rpc-statd.service has failed -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit rpc-statd.service has failed. -- -- The result is failed. May 29 00:41:00 g5eas systemd[1]: Unit rpc-statd.service entered failed state. May 29 00:41:00 g5eas rpc.statd[709]: Version 1.3.0 starting May 29 00:41:00 g5eas rpc.statd[709]: Flags: TI-RPC [end] I see no similar problem in Factory or Cauldron using identical fstab entries and mount syntax. What needs to be done to eliminate this delay? -- "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/

3 12

Beta / Final release criteria for Workstation
by Adam Williamson 14 Oct '14

14 Oct '14

Hi, folks. I wanted to ask if you envisage a need for release criteria for Workstation at Beta (or Final) over and above those that already exist for 'desktop' stuff. Areas I notice: SSSD is listed in the tech spec. We have server-side requirements for FreeIPA in the Server product; do we want to formulate client-side requirements? We don't really have criteria relating to a11y or complex input methods; this isn't Workstation-y in particular, but something that might be interesting? Appearance is something we'd want to enforce if it were actually done, but I get the impression the Qt variant of Adwaita isn't actually written yet. Functional requirements for the 'core apps' - we have requirements for graphical updating (but not package install), web browser, and terminal in the current criteria, but not for text editor, file manager, Boxes, or 'developer assistant'. Do remember that anything we write in the release criteria is something we expect to enforce: if you don't actually want the release to be delayed if it's not done, best not to have a criterion for it. More aspirational 'to-do' or 'it'd be good if...' lists can be handled somewhere else, I don't know/care where, but not in the criteria :) Thanks folks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

3 8

Problem booting/install Fedora-Server-netinst-x86_64-21_Alpha.iso
by Jon Ingason 11 Oct '14

11 Oct '14

I am trying to make netinstall from Fedora-Server-netinst-x86_64-21_Alpha on two PC. One is HP Compaq DC5850 with AMD Athlon P5200B and the other is Dell Dimension 3100 with Intel Celeron 3.06 GHz. I downloaded Fedora-Server-netinst-x86_64-21_Alpha.iso and run sha256sum with OK results. Then burned a CD with K3b. When I tryed to boot the CD on HP Compaq DC5850 it just restart again and again (looping). On the Dell Dimension 3100 it just stoped displaying: ISOLINUX 6.02 There was no problem making netinstall on VM in KVM/qemu. So the question is what can be wrong? I will burn Fedora-Server-DVD-x86_64-21_Alpha.iso on DVD and see if I can install F21-Alpha from thw DVD. -- Regards Jon Ingason

4 7

Proposing new dual booting release criteria
by Michael Catanzaro 06 Oct '14

06 Oct '14

Hi all, There's been some discussion on the desktop list, beginning at [1], about Workstation's requirements for dual booting in F21. The Workstation technical specification says the following: "One aspect of storage configuration that will be needed is support for dual-boot setups (preserving preexisting Windows or OS X installations), since e.g. students may be required to run software on those platforms for their coursework." [2] Unfortunately, due to some bugs in anaconda we are not currently meeting the requirement for preserving previous Windows and OS X installations, and the story for preserving previous Linux systems (which is not a requirement) is not any better. A good summary of these bugs is at the bottom of [3]. We think these issues need to be treated very seriously, since we do not expect Workstation users to be able to recover an operating system when it is missing from the boot menu. In short: "No boot entry or nonfunctional boot entry -> user is up a creek -> Fedora Workstation is bad" I therefore propose some new release criteria, based on the consensus from the desktop list. It's possible that these new criteria will directly result in further significant delays to the release of F21, since there are four open bugs that would fall under these criteria, but harming the user's previous OS is so severe that we should block on them anyway. Fedora will not become widely popular if it remains dangerous to install. Windows ======= Our current release criterion is: "The installer must be able to install into free space alongside an existing clean Windows installation and, when performing a BIOS (not UEFI) installation, install a bootloader which can boot into both Windows and Fedora." I propose the language be amended to the following: "The installer must be able to install into free space alongside an existing clean Windows installation and install a bootloader which can boot into both Windows and Fedora." Rationale: many modern Windows systems no longer have a boot menu that is accessible before the system boots. If Fedora Workstation were installed on such a system, the user would not be able to recover Windows. Open bugs that would be covered by this criterion: https://bugzilla.redhat.com/show_bug.cgi?id=986731 https://bugzilla.redhat.com/show_bug.cgi?id=1010704 OS X ==== We currently do not have any release criterion that applies to dual booting with OS X. Since our Mac support is very poor and has no prospect of near term improvement -- in particular, we have concerns that running Fedora on a Mac has caused at least one Mac to overheat and die -- the consensus seems to be that dual booting with OS X should not be a requirement. However, it's also not OK to destroy the user's OS X without warning. I propose the following final release criterion: "The installer must be able to install into free space alongside an existing clean OS X installation and install a bootloader which can boot into both OS X and Fedora, OR the installer must prominently warn the user that he may be unable to boot OS X after installation, allowing the user to cancel installation and reboot to OS X." I think that requirement should be easy to meet, so I won't include links to the OS X bugs. Linux ===== We currently do not have any release criterion that applies to dual booting with other Linux systems. Dual booting with other Linux systems is NOT a requirement in the Workstation technical specification, but the consensus seems to be that it should have been. Therefore I propose the following criterion: "The installer must be able to install into free space alongside existing GNU/Linux installations and install a bootloader which can boot into the previously-installed systems and Fedora." I have no doubt that you will need to tweak the wording here, but the intent should be clear. If such a broad requirement isn't technically feasible, then let's discuss what would be. We want the criterion to cover these bugs: https://bugzilla.redhat.com/show_bug.cgi?id=825236 https://bugzilla.redhat.com/show_bug.cgi?id=964828 [1] https://lists.fedoraproject.org/pipermail/desktop/2014-June/009932.html [2] https://fedoraproject.org/wiki/Workstation/Technical_Specification#System_I… [3] https://lists.fedoraproject.org/pipermail/desktop/2014-June/009953.html

9 43

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