#141: proventester for pcfe?
------------------------------------------+---------------------------------
Reporter: pcfe | Owner: jlaska
Type: proventester request | Status: closed
Priority: major | Milestone:
Component: Proventester Mentor Request | Version:
Resolution: fixed | Keywords:
------------------------------------------+---------------------------------
Changes (by jlaska):
* status: assigned => closed
* resolution: => fixed
Comment:
Replying to [comment:2 pcfe]:
> Hi James,
>
> Replying to [comment:1 jlaska]:
> [...]
> > Once you have read the instructions, please confirm that you ...
>
> Yupp, read them before requesting the proventester flag and figured most
of it applies to what I do anyway ;-)
Indeed, thanks!
> > 1. have read and understand the instructions, and intend to follow
the instructions when testing Fedora critical path updates
>
> Not to the letter, my testmachines sit in a disconnected segment of the
lab here. Their software source is an internal server that mirrors it's
Fedora trees from funet (I get well over 10MB/s from that mirror, viva
Finland's modern infrastructure) once a day. So in general I lag by a day
or two. On single packages I can pull manually, but most of my testing
will have the 2 day lag until I have the packages. Is that OK?
I don't have issue with that. Most of the more popular, well
known+understood packages receive test feedback fairly quick. I could see
you (and your test setup) providing feedback on perhaps more involved or
less high-profile packages/subsystems.
> Secondly, 'you should perform a full system update from this repository
at least once a day.' does not apply to my situation, all my test machines
get frequently re-installed (while I have a few tens of test boxes at my
disposal, I have many more test cases than machines, so all my tests are
kickstart based. Meaning, if a package needs testing, I'll happily
kickstart the Fedora version required and hoover in updates-testing from
the local mirror, but said test machine may be running a completely
different distro later in the day and is almost guaranteed to have been
re-installed after a couple days). Again, if this does not fit the
proventester requirement, no hard feelings if you turn my application
down. The aim is to help Fedora and RHEL, not to brag about the
proventester flag ;-)
The use case described above does not conflict with the test procedures
for proventesters. One reason for suggesting an update is so that
proventesters can identify and report conflicts and dependency failures
reported during upgrade. I believe those errors will be reported when
installing while including ''updates'' and ''updates-testing'' as well, so
there shouldn't be any issues.
> > 2. understand how to enable the update-testing repository
>
> yeah, my kickstart files drop in repofiles in %post, dropping one with
updates-testing enabled is no issue.
>
> > 3. are familiar with providing test feedback using either the Bodhi
web interface, or the fedora-easy-karma utility
>
> Yeah, I used Bodhi in the past when feedback was requested in a BZ.
Can't use the easy-karma tool from the lab (the test boxes can only
connect to the install server to hoover ks and RPMs from there)
Using only the bodhi webui is still a valid option. With the new bodhi
release, there are feeds available for critpath updates in updates-
testing. Take a look at
https://admin.fedoraproject.org/updates/critpath?untested=True for
details. You may find that handy for staying on top of testing requests,
and identifying updates where you might have more experience in providing
meaningful feedback.
In the meantime, I have added you to the ''proventesters'' FAS group. Go
forth and happy testing! :)
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/141#comment:3>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
--
test mailing list
test@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
