#141 proventester for pcfe?
Closed: Fixed None Opened 13 years ago by pcfe.

Hi,

as I tend to regularly test Fedora and RHEL as part of my work, I figured I might as well apply for proventester status.

Please see the bugzilla bugs opened by pcfe@redhat.com to determine if my testing and bug reports are deemed good enough.

Red Hat employees will also be able to check the bugs that originated in the ticketing system and then got pushed to bugzilla later.

RU

PCFE


Greetings Patrick!

I'll be happy to sponsor you into the proventesters group. I'm familiar with your Fedora bugs (http://bit.ly/ck98Ze), and of course, we've discussed testing several times on #fedora-qa. Please take a moment to read through the [https://fedoraproject.org/wiki/Proven_tester proventester instructions]. Just a reminder, as proventesters, our job isn't to exhaustively find all defects in a software update. The focus is to determine whether the proposed software update negatively impacts core system functionality. Pay particular attention to the documented feedback procedures.

Once you have read the instructions, please confirm that you ...
1. have read and understand the instructions, and intend to follow the instructions when testing Fedora critical path updates
2. understand how to enable the update-testing repository
3. are familiar with providing test feedback using either the Bodhi web interface, or the fedora-easy-karma utility

You can also [https://admin.fedoraproject.org/accounts/group/view/proventesters apply for proventester membership in FAS]. Please let me know if you have any questions or concerns. Once I hear back, I'll sponsor your membership in the proventesters group.

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 ;-)

  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?

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 ;-)

  1. 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.

  1. 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)

RU

PCFE

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.

  1. 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.

  1. 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! :)

Login to comment on this ticket.

Metadata