[Fedora QA] #82: Update existing dual-boot tests and add to test plan
by fedora-badges
#82: Update existing dual-boot tests and add to test plan
---------------------------+------------------------------------------------
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=590661
RHBZ#590661 - GRUB bootloader should have a few seconds delay on a multi-
boot setup]
= analysis =
Due to RHBZ #590661, the dual-boot experience was not well understood and
tested for the final release. It was discovered late and unclear whether
this behavior was critical to Fedora success.
= enhancement recommendation =
Recommend updating existing dual-boot test cases, and create new test as
needed, to reflect updated dual-boot release criteria. Also, add tests to
the install matrix (depends on ticket#80).
The current tests concern dual-booting windows and Mac. I believe Mac is
no longer a primary concern. However, we may wish to add a test for dual-
booting Ubuntu or even Fedora.
See existing dual-boot tests at
https://fedoraproject.org/wiki/Category:Installer_Dual_Boot_Test_Cases
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/82>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
11 years, 10 months
[Fedora QA] #80: Add dual-boot release criteria
by fedora-badges
#80: Add dual-boot 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=590661
RHBZ#590661 - GRUB bootloader should have a few seconds delay on a multi-
boot setup]
= analysis =
Due to RHBZ #590661, the dual-boot experience was not well understood and
tested for the final release. It was discovered late and unclear whether
this behavior was critical to Fedora success.
= enhancement recommendation =
The user experience of dual-boot scenarios was not well understood, as a
result RHBZ #590661 did not clearly impact the release criteria.
Recommend reviewing and making adjustments to the release criteria for
dual-boot expectations.
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/80>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
12 years, 4 months
[Fedora QA] #93: Review options to reward key QA contributors
by fedora-badges
#93: Review options to reward key QA contributors
---------------------------+------------------------------------------------
Reporter: jlaska | Owner: jlaska
Type: enhancement | Status: new
Priority: major | Milestone: Fedora 14
Component: Wiki | Version:
Keywords: retrospective |
---------------------------+------------------------------------------------
= problem =
During Fedora 13, a small amount was available to reward several key QA
contributors for their efforts.
= analysis =
If possible, I'd like to repeat this in Fedora 14.
= enhancement recommendation =
What's the best way to say thanks?
1. Request and secure QA budget to reward key contributors
2. Researching reward options (maxamillion has discussed t-shirt ideas
with the design team)
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/93>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
12 years, 4 months
[Fedora QA] #89: Improve tracking blocker review status
by fedora-badges
#89: Improve tracking blocker review status
---------------------------+------------------------------------------------
Reporter: jlaska | Owner: poelstra
Type: enhancement | Status: new
Priority: major | Milestone: Fedora 14
Component: Wiki | Version:
Keywords: retrospective |
---------------------------+------------------------------------------------
= problem =
Several bugs were changed so they fell off the tracking lists for Fedora
13. For example...
* [http://bugzilla.redhat.com/505189 505189 - Going back to repo UI
screen and and modifying Installation Repo causes traceback]
* [http://bugzilla.redhat.com/577803 577803 - Adding repository
requiring network fails if network is down]
= analysis =
In F-13, a bugzilla keyword was used to denote blocker status. However,
aside from reviewing bugzilla comments, there was no query-able method to
determine whether a blocker request is open, approved or denied. This led
to several Fedora 13 bugs that were 1) fixed in Rawhide, 2) Moved to
MODIFIED or CLOSED and not included, but not included in Fedora 13 (e.g.
RHBZ #505189 and RHBZ #577803).
Not knowing which bugs were already reviewed, also introduced time wasted
reviewing previously reviewed bugs during blocker review meetings.
= enhancement recommendation =
Recommend reviewing process changes to avoid the scenarios leading up to
RHBZ #505189 and RHBZ #577803. Some options discussed so far include
1. Document usage of bugzilla flags (suggested by jkeating) to track
blocker requests. This likely involves creating a ''bot'' to police the
tags?
2. Hardening the current keyword-based mechanism.
Additional discussion points include:
1. Document generating exception report and document action plan for
CLOSED Blocker bugs that did not go through VERIFIED.
2. More frequent nag mails leading up to release milestones. Notification
of NEW or ASSIGNED bugs goes to the maintainer, and MODIFIED bugs goes to
QA.
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/89>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
12 years, 4 months
[Fedora QA] #149: Mentor Request
by fedora-badges
#149: Mentor Request
-----------------------------------------+----------------------------------
Reporter: hellork | Owner:
Type: proventester request | Status: new
Priority: minor | Milestone:
Component: Proventester Mentor Request | Version:
Keywords: |
-----------------------------------------+----------------------------------
= phenomenon =
I am interested in joining the protesters and I'm requesting a mentor.
= reason =
I have been filing bug reports and working on submitting a couple new
projects to Fedora. I have a good working knowledge of Yum update, C, C++,
Makefiles, Bash, Python, Java, and RPM, packaging, etc.
= recommendation =
Sign me up!
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/149>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
12 years, 4 months
[Fedora QA] #145: Request to join ProvenTester
by fedora-badges
#145: Request to join ProvenTester
-----------------------------------------+----------------------------------
Reporter: dbhole | Owner:
Type: proventester request | Status: new
Priority: major | Milestone:
Component: Proventester Mentor Request | Version:
Keywords: |
-----------------------------------------+----------------------------------
OpenJDK is a widely used package, and has quarterly security updates (at
the very least). While we (devel and qe) team test it, there is no way for
us to set a +1 karma as a proven-tester.
To that end, I would like to apply for proven tester status. In addition
to OpenJDK, this will also allow me to test and set the proper Karma for
other packages our team owns.
I'd be happy to follow and training guidelines laid out by a Proventester
Mentor.
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/145>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
12 years, 4 months
[Fedora QA] #98: Request for a Mentor
by fedora-badges
#98: Request for a Mentor
-----------------------------------------+----------------------------------
Reporter: jdulaney | Owner:
Type: proventester request | Status: new
Priority: major | Milestone:
Component: Proventester Mentor Request | Version:
Keywords: |
-----------------------------------------+----------------------------------
I would like to now formally request a Proven Tester Mentor. I have been
running Fedora since FC1, generally updating every other release (I
skipped 9 and went straight to 10). I have several boxes so as to get
different hardware involved.
Thanks,
John H. Dulaney
https://fedoraproject.org/wiki/User:Jdulaney
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/98>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
12 years, 4 months
[Fedora QA] #60: Devise a better location for critpath.txt
by fedora-badges
#60: Devise a better location for critpath.txt
-------------------------+--------------------------------------------------
Reporter: kparal | Owner:
Type: enhancement | Status: new
Priority: major | Milestone:
Component: Wiki | Version:
Keywords: |
-------------------------+--------------------------------------------------
critpath.txt lists critical path packages [1]. Currently it is referenced
as
{{{
http://kojipkgs.fedoraproject.org/mash/rawhide-<<CURRENT
DATE>>/logs/critpath.txt
}}}
or
{{{
http://kojipkgs.fedoraproject.org/mash/rawhide-<<YESTERDAY
DATE>>/logs/critpath.txt
}}}
depending on which page. Similarly for branched releases.
This is not optimal. Very often the url just doesn't work. For example at
the time of writing critpath.txt on F13 Alpha Release Criteria page [2]
references rawhide-20100407/ directory, where critpath.txt is not
available. Nor it is available in rawhide-20100406/ directory. Only in
rawhide-20100405/ it is finally available.
The very page Critical Path Packages [1] references critpath.txt for
Branched release, which is available ATM, but also references critpath.txt
for Rawhide, which is again not available.
Let's imagine other use case - some automated tool must decide whether
package in the critical path. It can't rely on path which are constantly
changing and sometimes are not available.
critpath.txt is created dynamically, so we probably must have the contents
created every day or so. But we should devise such mechanism that the
location is stable and the file is always available (if new contents fails
to create, the old contents is still available). That will also allow
third-party tools to rely on it.
[1] https://fedoraproject.org/wiki/Critical_Path_Packages [[BR]]
[2] https://fedoraproject.org/wiki/Fedora_13_Alpha_Release_Criteria
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/60>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
12 years, 4 months
[Fedora QA] #134: Clarify the ISO to USB tests
by fedora-badges
#134: Clarify the ISO to USB tests
-------------------------+--------------------------------------------------
Reporter: rhe | Owner:
Type: enhancement | Status: new
Priority: major | Milestone:
Component: Test Review | Version:
Keywords: |
-------------------------+--------------------------------------------------
We've heard many users installing by writing ISO to USB drive and having
problems about it. So it's better to have a clear story from anaconda or
whoever on what exactly is supported in terms of writing the DVD image to
USB, and what isn't. It would be good to clear it up and add some specific
install validation tests for it.
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/134>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
12 years, 8 months