[Fedora QA] #221: Reduce Blocker Bug Review Meeting Length
by fedora-badges
#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
9 years, 2 months
[Fedora QA] #152: Test Cases Management
by fedora-badges
#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
9 years, 2 months
[Fedora QA] #81: Add i18n release criteria
by fedora-badges
#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
9 years, 2 months
[Fedora QA] #46: Write Test cases for LXDE components.
by fedora-badges
#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
9 years, 3 months
mount -t nfs delayed
by Felix Miata
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/
9 years, 6 months
Beta / Final release criteria for Workstation
by Adam Williamson
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
9 years, 6 months
Problem booting/install Fedora-Server-netinst-x86_64-21_Alpha.iso
by Jon Ingason
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
9 years, 6 months
Proposing new dual booting release criteria
by Michael Catanzaro
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...
[3]
https://lists.fedoraproject.org/pipermail/desktop/2014-June/009953.html
9 years, 6 months
