#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
#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
#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
#236: No qa test for making sure that the boot.iso is hybridised
--------------------+-------------------------------------------------------
Reporter: ausil | Owner: adamw
Type: defect | Status: new
Priority: major | Milestone:
Component: Trac | Version:
Keywords: |
--------------------+-------------------------------------------------------
= bug description =
F-16 alpha shipped witha boot.iso that did not have isohybrid run on it,
this means you can not just dd it to a usb drive and boot it.
= bug analysis =
slipped though as there was no test case
= fix recommendation =
lorax has been fixed, but we should make sure we cover it in testing.
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/236>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
#170: Request for F15 Power Management test day
-----------------------------------------+----------------------------------
Reporter: jskarvad | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: Proventester Mentor Request | Version:
Keywords: |
-----------------------------------------+----------------------------------
We would like to have the Power Management test day on 2011-03-24 (or
maybe later). Such event would help us to test the PM functionality
(especially suspend / hibernate and tuned profiles) across wide HW
configurations. We are able to prepare detailed test instructions and
scripts for test semi-automation. Feature page:
https://fedoraproject.org/wiki/Features/PowerManagementF15
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/170>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
Hey, folks. So, currently the Beta criteria state:
"The installer must be able to use all kickstart delivery methods"
This is probably over-ambitious for Beta. We have some pretty odd
kickstart delivery methods:
https://fedoraproject.org/wiki/QA:Testcase_Kickstart_File_Path_Ks_Cfghttps://fedoraproject.org/wiki/QA:Testcase_Kickstart_Hd_Device_Path_Ks_Cfg
that are only really useful in pretty unusual scenarios. In fact the
first of these is broken in F16 Beta and we decided to go ahead and
release it anyway (on the basis that we agreed this criterion should be
changed, which is why I'm proposing a change now), and the world has not
ended.
I'd propose at least this much change:
for Beta, the criterion should read
"The installer must be able to use the HTTP and NFS kickstart delivery
methods"
as those are the two that are really useful in most situations, and we
move
"The installer must be able to use all kickstart delivery methods"
to be a Final criterion. Thoughts? The Beta criterion is a bit more
'technology-specific' than I usually like to make the criteria, but I
don't think we're that likely to discover any exciting new protocols in
the foreseeable future, so specifying HTTP and NFS is probably
reasonably future-proof.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
# Fedora Quality Assurance Meeting
# Date: 2011-07-11
# Time: 15:00 UTC (11:00 EDT, 17:00 CEST) [1]
# Location: #fedora-meeting on irc.freenode.net
Greetings testers!
Quite a few topics to discuss today. Many of them are quick updates, so
I don't anticipate going longer than our time slot. As always, feel
free to respond to this mail with additional
topics/suggestions/concerns.
== Proposed Agenda Topics ==
https://fedoraproject.org/wiki/QA/Meetings/20110711
1. Desktop duplicate application names
2. Fedora 16 RATS!
3. AutoQA update
4. R^3 - Retrospective recommendation tasks available
5. Cloud SIG Testing update -
https://fedorahosted.org/fedora-qa/ticket/212
6. Security Lab SPIN matrix -
https://fedorahosted.org/fedora-qa/ticket/207
7. Open Discussion - <your topic here>
Thanks,
James
[1] https://fedoraproject.org/wiki/Infrastructure/UTCHowto
Quick question,
how do rel-eng guys know which updates are OK to push to stable during freeze and which are not? For example we have the final freeze now. Some packages like this:
https://admin.fedoraproject.org/updates/FEDORA-2011-14932
are needed to be pushed to stable repo, so they have an exception from the freeze. Blocker and NTH updates have also exception from the freeze. But other packages may be also requesting push to stable and not be eligible for an exception. How do the rel-eng guys know which packages to push and which not to?
Thanks.
On my laptop, pressing the 'power' button in current f16 causes the
system to shut down, not suspend - even though the dconf preference says
suspend.
Anyone else noticed this lately?
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net