[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] #236: No qa test for making sure that the boot.iso is hybridised
by fedora-badges
#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
12 years, 4 months
Release criteria: virtualization tweak
by Adam Williamson
Hey, all. pjones pointed out at a recent blocker review meeting that the
Beta virt criterion:
"The release must boot successfully as a virtual guest in a situation
where the virtual host is running the same release (using Fedora's
current preferred virtualization technology)"
doesn't really imply that virtual host functionality must work; only
that _if_ virtual host functionality is working, then virtual guest
functionality must work. This was not really our intent with the
criterion, we intended to require both to work at Beta stage. So here's
a proposed improvement:
"The release must be able to self-host using Fedora's current preferred
virtualization technology: that is, the release must be able to act as a
virtual host, and must also successfully install and boot as a virtual
guest when running on a host which is also running the release"
I'm still not super happy with the wording, but I guess it's clearer.
Any better ideas?
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
12 years, 6 months
Final Release Criterion for Xen DomU
by Tim Flink
During the discussion around Xen DomU support as a beta release
criterion in the Fedora QA meeting today, the question of blocking for
DomU came up.
Specifically, do we want to have Xen DomU support as a final release
criteria?
I can think of two arguments for making it a release criterion:
1. If install as DomU doesn't work at final release, it becomes much
more difficult to install as DomU for that release without spinning
custom install media.
2. Amazon EC2 is based on Xen, DomU support could affect our ability to
release on EC2.
Another thought is that Fedora 16 is going to be the first release in a
while that supports running as Xen Dom0. It seems a bit silly to have
support for Dom0 and not have the ability to run as DomU.
Anyhow, thoughts around making DomU support a final release criterion?
Tim
12 years, 6 months
fedora 16 dvd or network install ?
by cornel panceac
i've downloaded de x86 fedora 16 dvd install iso so that i'll no longer need
the network. during the install, i was asked to configure a wired network
interface (which i did), then proceeded to the install. later i've seen that
the usb stick from which i started the install (which contains the files
from dvd) is not used but instead the ethernet connection is the install
source. i've never tell anaconda to install from the internet (but maybe the
network repos were autoamgically selected). is this by design?
on the other hand, i've noticed that the 3.x kernel freezes often on my x40
thinkpad. is this a known issue? (i'll test the hardware anyway, after
install.)
12 years, 6 months